[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CTH46BGKXH80RWS876Y2CW":3,"skill-same:01M6CTH46BGKXH80RWS876Y2CW":74},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":31,"linkOnly":32,"markdownContent":33,"markdownBody":34,"frontMatter":35,"refName":38,"commitSha":39,"skillDirectory":40,"forksCount":41,"repositoryHtmlUrl":42,"repositoryHomepageUrl":6,"ownerHtmlUrl":43,"ownerBlogUrl":6,"ownerDescription":44,"updatedAt":45,"install":46,"resources":59},"01M6CTH46BGKXH80RWS876Y2CW","workflow-router",null,"Maps an objective to the artifacts, stages and agents it needs. Use when deciding what happens next or which agents to involve.","vibbs\u002Fcompany-os","vibbs","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F7379149?v=4","01M6CT6M03CAS1H7RA89F3965B","Vibbs Dod","01M6CT6M4MY60C9FFQ3AAR2RSK",6,"MIT","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fworkflow-router\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30],"workflow","router","workflow router","artifacts","use","maps","next","2026-11-10 10:12:30",false,"---\nname: workflow-router\ndescription: Maps an objective to the artifacts, stages and agents it needs. Use when deciding what happens next or which agents to involve.\nruntimes:\n  claude:\n    user-invocable: false\n---\n\n# Workflow Router\n\n## Reference\n- **ID**: S-ORG-01\n- **Category**: Orchestration\n- **Inputs**: objective or request, current artifact state (artifacts\u002F), company.config.yaml\n- **Outputs**: execution plan with stages, artifacts, and agent assignments\n- **Used by**: Orchestrator Agent\n- **Tool scripts**: .\u002Ftools\u002Fartifact\u002Fvalidate.sh, .\u002Ftools\u002Fartifact\u002Fcheck-gate.sh, .\u002Ftools\u002Fregistry\u002Fsearch-skill.sh\n\n## Purpose\n\nGiven any objective, determine the sequence of artifacts, stages, and agents required to deliver it. This is the Orchestrator's primary planning skill.\n\n## When to Use\n\n- User states an objective (\"Build feature X\", \"Launch product Y\", \"Fix bug Z\")\n- Orchestrator needs to decide what happens next\n- A stage is complete and the next step must be determined\n\n## Routing Procedure\n\n### Step 0: Check Configuration\n\nBefore routing any objective, verify `company.config.yaml` exists and has non-empty values for at least `company.name` and `tech_stack.language`. If the config is missing or all fields are empty, route to `\u002Fsetup` first — agents need a configured tech stack to make good decisions.\n\n### Step 1: Classify the Objective\n\nDetermine the type of work:\n\n| Type | Description | Typical Flow |\n|------|-------------|--------------|\n| **New Feature** | Building something that doesn't exist | Full pipeline (PRD → RFC → Build → Test → Release) |\n| **Bug Fix** | Something is broken | Triage → Fix → Test → Release |\n| **Improvement** | Enhancing existing functionality | Mini-PRD → RFC (optional) → Build → Test → Release |\n| **Research\u002FSpike** | Understanding before deciding | Research → Decision Memo |\n| **Launch** | Taking something live | QA gate → Growth assets → Release |\n| **Compliance** | Security\u002Fprivacy\u002Flegal requirement | Risk review → Remediation → Verification |\n| **Prototype\u002FDemo** | Time-boxed proof-of-concept or investor demo | Mini-PRD (3 AC max) → Build → Demo script (skip RFC\u002FQA\u002FGrowth) |\n| **Refactor \u002F Tech Debt** | Internal code quality improvement, no user-facing change | RFC (if large scope) → Build → Test → Release |\n| **Dependency Upgrade** | Updating libraries or frameworks to newer versions | Scan → RFC (if breaking) → Build → Test |\n| **GTM \u002F Market Validation** | Validating market demand, launching MVP, or structured GTM push | ICP → Interviews → Pain Synthesis → LOIs → Launch Assets → Distribution (skip Engineering entirely) |\n\n### Step 2: Check Current State\n\nInventory what artifacts already exist for this objective:\n\n```\n1. Check artifacts\u002Fprds\u002F — does a relevant PRD exist?\n2. Check artifacts\u002Frfcs\u002F — does an RFC exist?\n3. Check artifacts\u002Ftest-plans\u002F — does a test plan exist?\n4. Check artifacts\u002Fqa-reports\u002F — has QA been done?\n5. If the user mentions existing artifacts outside the system (Google Docs, Notion, Confluence, local files), route to `\u002Fartifact-import` before building the execution plan. Imported artifacts enter at `review` status and can be promoted to `approved` to unblock downstream stages.\n6. Check artifacts\u002Fsecurity-reviews\u002F — has risk been assessed?\n7. Check artifacts\u002Flaunch-briefs\u002F — are launch assets ready?\n```\n\nWhatever is missing determines what still needs to happen.\n\n### Step 3: Build the Execution Plan\n\nFor each missing artifact, assign the responsible agent and required skills:\n\n| Artifact Needed | Agent | Primary Skill | Prerequisite |\n|----------------|-------|---------------|--------------|\n| PRD | Product Agent | prd-writer | Objective defined |\n| RFC \u002F Architecture | Engineering Agent | architecture-draft | PRD approved |\n| API Contract | Engineering Agent | api-contract-designer | RFC approved |\n| Threat Model | Ops & Risk Agent | threat-modeling | RFC exists |\n| Implementation | Engineering Agent | implementation-decomposer | RFC + API contract |\n| Test Plan | QA Agent | test-plan-generator | PRD + RFC exist |\n| QA Report | QA Agent | release-readiness-gate | Tests executed |\n| Launch Brief | Growth Agent | positioning-messaging | PRD + release date |\n| Security Review | Ops & Risk Agent | threat-modeling | RFC exists |\n\n### Step 4: Identify Parallelizable Work\n\nSome stages can run concurrently:\n\n```\nSequential (must be in order):\n  PRD → RFC → Implementation → QA Report → Release\n\nParallel branches (can run alongside implementation):\n  RFC → Threat Model (Ops & Risk)\n  RFC → Test Plan (QA)\n  PRD → Launch Brief (Growth)\n```\n\n### Step 5: Define Stage Gates\n\nEach stage transition requires validation. Use `.\u002Ftools\u002Fartifact\u002Fcheck-gate.sh` to verify:\n\n| Transition | Gate Command | Checks |\n|-----------|-------------|--------|\n| PRD → RFC | `check-gate.sh prd-to-rfc \u003Cprd>` | PRD approved, acceptance criteria present |\n| RFC → Implementation | `check-gate.sh rfc-to-impl \u003Crfc>` | RFC approved, parent PRD approved |\n| Implementation → QA | `check-gate.sh impl-to-qa \u003Crfc>` | RFC approved, test plan exists |\n| QA → Release | `check-gate.sh release \u003Cprd>` | All artifacts exist and approved |\n\n### Step 6: Output the Plan\n\nProduce a structured execution plan:\n\n```markdown\n## Execution Plan: [Objective]\n\n### Current State\n- [x] PRD: PRD-001 (approved)\n- [ ] RFC: not started\n- [ ] Threat Model: not started\n- [ ] Implementation: not started\n- [ ] Test Plan: not started\n- [ ] QA Report: not started\n- [ ] Launch Brief: not started\n\n### Next Actions\n1. **Engineering Agent** → produce RFC using architecture-draft (depends on: PRD-001)\n2. **Engineering Agent** → produce API contract using api-contract-designer (depends on: RFC)\n3. **Ops & Risk Agent** → produce threat model using threat-modeling (depends on: RFC) [parallel]\n\n### Stage Gates\n- RFC must be approved before implementation starts\n- Threat model must exist (even minimal) before release\n- QA report must pass before release approval\n```\n\n## Shortcut Flows\n\n### Bug Fix Flow (Expedited)\n1. Engineering Agent triages and fixes\n2. QA Agent validates fix (regression check)\n3. Orchestrator approves release\n- Skip: PRD, RFC, Growth, Ops (unless security-related)\n\n### Research Spike Flow\n1. Engineering Agent investigates\n2. Orchestrator produces Decision Memo (decision-memo-writer)\n- Skip: everything else until decision is made\n\n### Prototype\u002FDemo Flow (Time-Boxed)\n1. Product Agent produces a mini-PRD (3 acceptance criteria max, no success metrics required)\n2. Engineering Agent builds directly (no RFC, no API contract, no security review)\n3. Orchestrator produces demo script with talking points\n- Skip: RFC, threat model, test plan, QA report, launch brief, full release gate\n- Prototype rules: no tests required, hardcoded values acceptable, skip lint\n- Keywords that trigger this flow: \"prototype\", \"demo\", \"proof of concept\", \"MVP test\", \"investor demo\", \"hackathon\", \"spike with code\"\n- **Exit criteria**: Either the prototype proves\u002Fdisproves the hypothesis, or graduate to full `\u002Fship` flow\n- After prototype: run `\u002Fship` to graduate the prototype to production quality (PRD gets expanded, RFC gets created, code gets refactored)\n\n### Refactor \u002F Tech Debt Flow\n1. Engineering Agent leads. Skip PRD — no user-facing change\n2. RFC required if touching >3 files or changing interfaces\n3. Build → Test → Release\n- Skip: PRD, Growth, Ops (unless changing security-sensitive code)\n\n### Dependency Upgrade Flow\n1. Engineering Agent scans for breaking changes\n2. RFC only if upgrade changes APIs or requires migration\n3. Build → Test\n- Skip: PRD, Growth (unless upgrade introduces user-visible changes)\n\n### GTM \u002F Market Validation Flow\n1. Growth Agent runs GTM Sprint skill (time-boxed 7\u002F14\u002F21 days)\n2. Product Agent assists with ICP positioning and customer conversations\n3. Growth Agent produces launch assets and distribution playbooks\n4. Sprint concludes with GTM Sprint Report\n- Skip: Engineering entirely (no code built), RFC, threat model, QA\n- Keywords: \"go to market\", \"GTM\", \"validate market\", \"find customers\", \"launch plan\", \"do people want this\", \"LOI\", \"market validation\"\n- **Exit criteria**: Either proceed to `\u002Fship` to build the product, pivot positioning, expand ICP, or pause\n- Best for: idea stage without existing product, MVP launch, new market entry, repositioning\n\n## Quality Checklist\n\n- [ ] Objective type correctly classified\n- [ ] All existing artifacts inventoried\n- [ ] Missing artifacts identified with responsible agents\n- [ ] Dependencies between stages are explicit\n- [ ] Parallel work identified\n- [ ] Stage gates defined with specific criteria\n- [ ] Plan is actionable (next action is clear)\n- [ ] Prototype\u002FDemo objectives correctly identified (not routed through full pipeline)\n","# Workflow Router\n\n## Reference\n- **ID**: S-ORG-01\n- **Category**: Orchestration\n- **Inputs**: objective or request, current artifact state (artifacts\u002F), company.config.yaml\n- **Outputs**: execution plan with stages, artifacts, and agent assignments\n- **Used by**: Orchestrator Agent\n- **Tool scripts**: .\u002Ftools\u002Fartifact\u002Fvalidate.sh, .\u002Ftools\u002Fartifact\u002Fcheck-gate.sh, .\u002Ftools\u002Fregistry\u002Fsearch-skill.sh\n\n## Purpose\n\nGiven any objective, determine the sequence of artifacts, stages, and agents required to deliver it. This is the Orchestrator's primary planning skill.\n\n## When to Use\n\n- User states an objective (\"Build feature X\", \"Launch product Y\", \"Fix bug Z\")\n- Orchestrator needs to decide what happens next\n- A stage is complete and the next step must be determined\n\n## Routing Procedure\n\n### Step 0: Check Configuration\n\nBefore routing any objective, verify `company.config.yaml` exists and has non-empty values for at least `company.name` and `tech_stack.language`. If the config is missing or all fields are empty, route to `\u002Fsetup` first — agents need a configured tech stack to make good decisions.\n\n### Step 1: Classify the Objective\n\nDetermine the type of work:\n\n| Type | Description | Typical Flow |\n|------|-------------|--------------|\n| **New Feature** | Building something that doesn't exist | Full pipeline (PRD → RFC → Build → Test → Release) |\n| **Bug Fix** | Something is broken | Triage → Fix → Test → Release |\n| **Improvement** | Enhancing existing functionality | Mini-PRD → RFC (optional) → Build → Test → Release |\n| **Research\u002FSpike** | Understanding before deciding | Research → Decision Memo |\n| **Launch** | Taking something live | QA gate → Growth assets → Release |\n| **Compliance** | Security\u002Fprivacy\u002Flegal requirement | Risk review → Remediation → Verification |\n| **Prototype\u002FDemo** | Time-boxed proof-of-concept or investor demo | Mini-PRD (3 AC max) → Build → Demo script (skip RFC\u002FQA\u002FGrowth) |\n| **Refactor \u002F Tech Debt** | Internal code quality improvement, no user-facing change | RFC (if large scope) → Build → Test → Release |\n| **Dependency Upgrade** | Updating libraries or frameworks to newer versions | Scan → RFC (if breaking) → Build → Test |\n| **GTM \u002F Market Validation** | Validating market demand, launching MVP, or structured GTM push | ICP → Interviews → Pain Synthesis → LOIs → Launch Assets → Distribution (skip Engineering entirely) |\n\n### Step 2: Check Current State\n\nInventory what artifacts already exist for this objective:\n\n```\n1. Check artifacts\u002Fprds\u002F — does a relevant PRD exist?\n2. Check artifacts\u002Frfcs\u002F — does an RFC exist?\n3. Check artifacts\u002Ftest-plans\u002F — does a test plan exist?\n4. Check artifacts\u002Fqa-reports\u002F — has QA been done?\n5. If the user mentions existing artifacts outside the system (Google Docs, Notion, Confluence, local files), route to `\u002Fartifact-import` before building the execution plan. Imported artifacts enter at `review` status and can be promoted to `approved` to unblock downstream stages.\n6. Check artifacts\u002Fsecurity-reviews\u002F — has risk been assessed?\n7. Check artifacts\u002Flaunch-briefs\u002F — are launch assets ready?\n```\n\nWhatever is missing determines what still needs to happen.\n\n### Step 3: Build the Execution Plan\n\nFor each missing artifact, assign the responsible agent and required skills:\n\n| Artifact Needed | Agent | Primary Skill | Prerequisite |\n|----------------|-------|---------------|--------------|\n| PRD | Product Agent | prd-writer | Objective defined |\n| RFC \u002F Architecture | Engineering Agent | architecture-draft | PRD approved |\n| API Contract | Engineering Agent | api-contract-designer | RFC approved |\n| Threat Model | Ops & Risk Agent | threat-modeling | RFC exists |\n| Implementation | Engineering Agent | implementation-decomposer | RFC + API contract |\n| Test Plan | QA Agent | test-plan-generator | PRD + RFC exist |\n| QA Report | QA Agent | release-readiness-gate | Tests executed |\n| Launch Brief | Growth Agent | positioning-messaging | PRD + release date |\n| Security Review | Ops & Risk Agent | threat-modeling | RFC exists |\n\n### Step 4: Identify Parallelizable Work\n\nSome stages can run concurrently:\n\n```\nSequential (must be in order):\n  PRD → RFC → Implementation → QA Report → Release\n\nParallel branches (can run alongside implementation):\n  RFC → Threat Model (Ops & Risk)\n  RFC → Test Plan (QA)\n  PRD → Launch Brief (Growth)\n```\n\n### Step 5: Define Stage Gates\n\nEach stage transition requires validation. Use `.\u002Ftools\u002Fartifact\u002Fcheck-gate.sh` to verify:\n\n| Transition | Gate Command | Checks |\n|-----------|-------------|--------|\n| PRD → RFC | `check-gate.sh prd-to-rfc \u003Cprd>` | PRD approved, acceptance criteria present |\n| RFC → Implementation | `check-gate.sh rfc-to-impl \u003Crfc>` | RFC approved, parent PRD approved |\n| Implementation → QA | `check-gate.sh impl-to-qa \u003Crfc>` | RFC approved, test plan exists |\n| QA → Release | `check-gate.sh release \u003Cprd>` | All artifacts exist and approved |\n\n### Step 6: Output the Plan\n\nProduce a structured execution plan:\n\n```markdown\n## Execution Plan: [Objective]\n\n### Current State\n- [x] PRD: PRD-001 (approved)\n- [ ] RFC: not started\n- [ ] Threat Model: not started\n- [ ] Implementation: not started\n- [ ] Test Plan: not started\n- [ ] QA Report: not started\n- [ ] Launch Brief: not started\n\n### Next Actions\n1. **Engineering Agent** → produce RFC using architecture-draft (depends on: PRD-001)\n2. **Engineering Agent** → produce API contract using api-contract-designer (depends on: RFC)\n3. **Ops & Risk Agent** → produce threat model using threat-modeling (depends on: RFC) [parallel]\n\n### Stage Gates\n- RFC must be approved before implementation starts\n- Threat model must exist (even minimal) before release\n- QA report must pass before release approval\n```\n\n## Shortcut Flows\n\n### Bug Fix Flow (Expedited)\n1. Engineering Agent triages and fixes\n2. QA Agent validates fix (regression check)\n3. Orchestrator approves release\n- Skip: PRD, RFC, Growth, Ops (unless security-related)\n\n### Research Spike Flow\n1. Engineering Agent investigates\n2. Orchestrator produces Decision Memo (decision-memo-writer)\n- Skip: everything else until decision is made\n\n### Prototype\u002FDemo Flow (Time-Boxed)\n1. Product Agent produces a mini-PRD (3 acceptance criteria max, no success metrics required)\n2. Engineering Agent builds directly (no RFC, no API contract, no security review)\n3. Orchestrator produces demo script with talking points\n- Skip: RFC, threat model, test plan, QA report, launch brief, full release gate\n- Prototype rules: no tests required, hardcoded values acceptable, skip lint\n- Keywords that trigger this flow: \"prototype\", \"demo\", \"proof of concept\", \"MVP test\", \"investor demo\", \"hackathon\", \"spike with code\"\n- **Exit criteria**: Either the prototype proves\u002Fdisproves the hypothesis, or graduate to full `\u002Fship` flow\n- After prototype: run `\u002Fship` to graduate the prototype to production quality (PRD gets expanded, RFC gets created, code gets refactored)\n\n### Refactor \u002F Tech Debt Flow\n1. Engineering Agent leads. Skip PRD — no user-facing change\n2. RFC required if touching >3 files or changing interfaces\n3. Build → Test → Release\n- Skip: PRD, Growth, Ops (unless changing security-sensitive code)\n\n### Dependency Upgrade Flow\n1. Engineering Agent scans for breaking changes\n2. RFC only if upgrade changes APIs or requires migration\n3. Build → Test\n- Skip: PRD, Growth (unless upgrade introduces user-visible changes)\n\n### GTM \u002F Market Validation Flow\n1. Growth Agent runs GTM Sprint skill (time-boxed 7\u002F14\u002F21 days)\n2. Product Agent assists with ICP positioning and customer conversations\n3. Growth Agent produces launch assets and distribution playbooks\n4. Sprint concludes with GTM Sprint Report\n- Skip: Engineering entirely (no code built), RFC, threat model, QA\n- Keywords: \"go to market\", \"GTM\", \"validate market\", \"find customers\", \"launch plan\", \"do people want this\", \"LOI\", \"market validation\"\n- **Exit criteria**: Either proceed to `\u002Fship` to build the product, pivot positioning, expand ICP, or pause\n- Best for: idea stage without existing product, MVP launch, new market entry, repositioning\n\n## Quality Checklist\n\n- [ ] Objective type correctly classified\n- [ ] All existing artifacts inventoried\n- [ ] Missing artifacts identified with responsible agents\n- [ ] Dependencies between stages are explicit\n- [ ] Parallel work identified\n- [ ] Stage gates defined with specific criteria\n- [ ] Plan is actionable (next action is clear)\n- [ ] Prototype\u002FDemo objectives correctly identified (not routed through full pipeline)\n",{"name":5,"runtimes":36,"description":7},{"claude":37},{"user-invocable":32},"main","e842fb6d0e04360c47db78bc2e2e2987314d64d4","os\u002Fskills\u002Fworkflow-router",2,"https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os","https:\u002F\u002Fgithub.com\u002Fvibbs","Principal Engineer · Applied AI · building ArcAI @ GrowthArc","2026-10-21 02:08:08",{"source":8,"skillName":5,"commands":47,"prompt":57,"zipAvailable":58},[48,51,54],{"tool":49,"command":50},"npx","npx skills add vibbs\u002Fcompany-os --skill workflow-router",{"tool":52,"command":53},"bunx","bunx skills add vibbs\u002Fcompany-os --skill workflow-router",{"tool":55,"command":56},"pnpm","pnpm dlx skills add vibbs\u002Fcompany-os --skill workflow-router","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fworkflow-router\u002FSKILL.md",true,[60,66,70],{"path":61,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":64,"sourceHtmlUrl":65},"bmad-skill-manifest.yaml","REFERENCE","参考文档",12,"https:\u002F\u002Fgithub.com\u002Fcodeasice\u002Fagentcore-presentation\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Fgds-e2e-scaffold\u002Fbmad-skill-manifest.yaml",{"path":67,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":68,"sourceHtmlUrl":69},"checklist.md",3355,"https:\u002F\u002Fgithub.com\u002Fcodeasice\u002Fagentcore-presentation\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Fgds-e2e-scaffold\u002Fchecklist.md",{"path":71,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":72,"sourceHtmlUrl":73},"workflow.md",11749,"https:\u002F\u002Fgithub.com\u002Fcodeasice\u002Fagentcore-presentation\u002Fblob\u002Fmaster\u002F.claude\u002Fskills\u002Fgds-e2e-scaffold\u002Fworkflow.md",[75,84,92,102,118,132],{"skillNo":76,"name":77,"nameZh":6,"description":78,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":79,"categories":80,"keywords":81,"publishedAt":31},"01M6CTHBW1E64ECYGD105N4S5E","typo-field","Fixture skill with a misspelled top-level field.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Ftypo-field\u002FSKILL.md",[],[82,83],"typo field","fixture skill",{"skillNo":85,"name":86,"nameZh":6,"description":87,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":88,"categories":89,"keywords":90,"publishedAt":31},"01M6CTHABTV8FKVDHFMMKPAV51","spaced-comments","Fixture skill with comments and spaces after block keys.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fspaced-comments\u002FSKILL.md",[],[91,83],"spaced comments",{"skillNo":93,"name":94,"nameZh":6,"description":95,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":96,"categories":97,"keywords":98,"publishedAt":31},"01M6CTH8MHC14KB65ZDHYBJW1N","crlf-comments","Fixture skill with Windows line endings.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fcrlf-comments\u002FSKILL.md",[],[99,100,83,101],"crlf comments","CRLF","windows",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":108,"publishedAt":31},"01M6CTH6TBKTDP9G8QB1Z2K0TY","claude-fields","Fixture skill using top-level fields Claude Code documents.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fskills\u002Fclaude-fields\u002FSKILL.md",[],[109,110,83,111,112,113,114,115,116,117],"claude fields","code","read","grep","src","explore","Bash","documents","testing",{"skillNo":119,"name":120,"nameZh":6,"description":121,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":122,"categories":123,"keywords":124,"publishedAt":31},"01M6CTH27653SRVP2FMEQN3J5B","weekly-review","Summarizes your week: what shipped, AI spend, support themes, security health and next priorities. Use at the end of each week.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fweekly-review\u002FSKILL.md",[],[125,126,127,30,28,128,129,130,131],"weekly review","review","priorities","health","save","support","security",{"skillNo":133,"name":134,"nameZh":6,"description":135,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":136,"categories":137,"keywords":146,"publishedAt":31},"01M6CTGZJD1D6WYYHXEP4TATCA","ux-research","Plans lean user research: method choice, interview scripts, usability tests and journey maps. Use when validating user needs or building personas before a PRD.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fux-research\u002FSKILL.md",[138,141],{"categoryNo":139,"categoryName":140,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[147,148,149,150,151,152,28,153,154,155,156,29,157],"ux","research","ux research","prd","choice","user","interview","lean","journey","personas","usability"]