[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CTCDVZ81ESVD9DJSNT1ZZ6":3,"skill-same:01M6CTCDVZ81ESVD9DJSNT1ZZ6":90},{"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":18,"publishedAt":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":39,"commitSha":40,"skillDirectory":41,"forksCount":42,"repositoryHtmlUrl":43,"repositoryHomepageUrl":6,"ownerHtmlUrl":44,"ownerBlogUrl":6,"ownerDescription":45,"updatedAt":46,"install":47,"resources":59},"01M6CTCDVZ81ESVD9DJSNT1ZZ6","artifact-import",null,"Brings existing documents (PRDs, RFCs, API specs, test plans) into Company OS with frontmatter, a type and links. Use when you already have docs outside this repo.","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\u002Fartifact-import\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29],"artifact","artifact import","docs","test","documents","content","file","api","repo","company os","use","2026-11-10 10:12:30",false,"---\nname: artifact-import\ndescription: Brings existing documents (PRDs, RFCs, API specs, test plans) into Company OS with frontmatter, a type and links. Use when you already have docs outside this repo.\nruntimes:\n  claude:\n    user-invocable: true\n    argument-hint: \"\u003Cfile path or pasted content>\"\n---\n\n# Artifact Import\n\nImports pre-existing documents from external sources (Google Docs, Notion, Confluence, local files, or inline-pasted content) into the Company OS artifact system with proper frontmatter, classification, and linking.\n\n## When to Use\n\n- You already have PRDs, RFCs, API specs or test plans in Google Docs, Notion, Confluence or local files.\n- You want the stage gates in `\u002Fship` to recognise that earlier work.\n- Not needed for new work: the other skills create artifacts with the right frontmatter.\n\n## Input Modes\n\n**Mode A — File-based**: User places exported documents (Markdown, HTML, or plain text) in the `imports\u002F` directory, then runs `\u002Fartifact-import`.\n\n**Mode B — Inline paste**: User pastes document content directly into the prompt (e.g., \"Import this as a PRD: [content]\"). The skill creates the artifact file from the pasted content.\n\nIf both modes are present, process both. If neither, prompt the user:\n> \"No files found in `imports\u002F` and no document content provided. Either export your docs as Markdown and place them in `imports\u002F`, or paste the content directly.\"\n\n## What You Will See\n\nBefore: a plain Markdown file you placed in `imports\u002F`.\n\n```markdown\n# User Authentication\n\n## Problem\nUsers cannot sign in with a work email.\n```\n\nAfter: the same text, with frontmatter added and the file moved to `artifacts\u002Fprds\u002FPRD-001-user-authentication.md`.\n\n```markdown\n---\nid: PRD-001\ntype: prd\ntitle: \"User Authentication\"\nstatus: review\ncreated: 2026-10-13\nauthor: imported\nparent: null\nchildren: []\ndepends_on: []\nblocks: []\ntags: [imported]\n---\n\n# User Authentication\n\n## Problem\nUsers cannot sign in with a work email.\n```\n\nIf the type is unclear, you will be asked one question and should answer with the type:\n\n```text\nI think `auth-notes.md` is an RFC, but it could also be a test plan. Which type should I assign?\n```\n\nReply `rfc` or `test-plan`. Imported files start at `review` status. You promote them to `approved` after checking them.\n\n## Procedure\n\n### Step 1: Detect and Read Sources\n\n1. Scan `imports\u002F` for any non-`.gitkeep` files\n2. Check the user's message for substantial document content (more than a few sentences of specification-like text)\n3. Read each file or inline block completely\n\n### Step 2: Classify Each Document\n\nDetermine the artifact type by analyzing content signals:\n\n| Content Signals | Artifact Type |\n|----------------|---------------|\n| Problem statement, user stories, acceptance criteria, success metrics, scope boundaries | `prd` |\n| System design, architecture, data model, modules, alternatives considered, migration plan | `rfc` |\n| API endpoints, request\u002Fresponse schemas, error codes, auth headers, pagination | `rfc` (API-focused) |\n| Test cases, test scenarios, coverage matrix, preconditions | `test-plan` |\n| Test results, pass\u002Ffail counts, regression results, coverage percentages | `qa-report` |\n| Threat model, security findings, vulnerability assessment, STRIDE analysis | `security-review` |\n| Launch plan, go-to-market, messaging, target audience, channels | `launch-brief` |\n| Decision record, ADR, rationale, alternatives considered, consequences | `decision-memo` |\n\n**Rules:**\n- If the user provides a type hint in their prompt (e.g., \"Import this PRD\"), trust the user over content analysis\n- If classification is ambiguous, ask: \"I think `filename.md` is an RFC, but it could also be a test plan. Which type should I assign?\"\n- If an API spec is imported alongside an RFC, ask: \"Embed API spec into the RFC's API Surface section, or create as a standalone artifact?\"\n\n### Step 3: Generate Artifact IDs\n\nScan `artifacts\u002F` recursively for all existing artifact IDs to find the highest number per type prefix, then auto-increment.\n\n| Type | Prefix | Example |\n|------|--------|---------|\n| prd | PRD | PRD-001 |\n| rfc | RFC | RFC-001 |\n| test-plan | TP | TP-001 |\n| qa-report | QA | QA-001 |\n| security-review | SR | SR-001 |\n| launch-brief | LB | LB-001 |\n| decision-memo | DM | DM-001 |\n\n### Step 4: Build Frontmatter\n\nGenerate complete YAML frontmatter for each artifact:\n\n```yaml\n---\nid: {generated-id}\ntype: {classified-type}\ntitle: \"{extracted-title}\"\nstatus: review\ncreated: {today or document's original date if found}\nauthor: imported\nparent: null\nchildren: []\ndepends_on: []\nblocks: []\ntags: [imported]\n---\n```\n\n**Notes:**\n- `status: review` — imported artifacts are not drafts (they already exist). Users promote to `approved` after reviewing.\n- `author: imported` — distinguishes agent-created from externally imported artifacts.\n- `tags: [imported]` — always include. Add additional tags extracted from content or context.\n- If the original document contains an author name, add as tag: `tags: [imported, author:jane-doe]`.\n\n### Step 5: Restructure Content (Best-Effort)\n\nMap imported content to Company OS templates where applicable:\n\n1. Read the relevant template if one exists (`prd-template.md` for PRDs, `rfc-template.md` for RFCs)\n2. Map imported headings to template headings (e.g., \"Goals\" → \"Success Metrics\")\n3. Preserve all original content — never delete imported text\n4. For template sections the import doesn't cover, insert the heading with: `\u003C!-- TODO: Fill in this section -->`\n5. For imported sections that don't map to the template, keep under an \"Additional Context (Imported)\" heading at the bottom\n6. For types without templates (test-plan, qa-report, security-review, launch-brief), apply frontmatter and preserve body as-is\n\n### Step 6: Detect Relationships and Link\n\nWhen multiple documents are imported together, detect relationships:\n\n1. **Explicit references**: Document mentions another artifact by name or ID\n2. **Topic coherence**: Documents about the same feature imported together are likely related\n3. **Type hierarchy**: Canonical order is PRD → RFC → test-plan\u002Fsecurity-review → qa-report → launch-brief. If multiple types are imported for the same feature, link following this hierarchy.\n4. **User hints**: If the user says \"these are all for the auth feature,\" link them as a family\n\nAfter all artifacts are written:\n- Run `.\u002Ftools\u002Fartifact\u002Flink.sh \u003Cparent-path> \u003Cchild-path>` for each detected parent-child pair\n- Run `.\u002Ftools\u002Fartifact\u002Fvalidate.sh --strict \u003Cpath>` on linked artifacts to verify bidirectional consistency\n\n### Step 7: Write Files and Validate\n\nFor each artifact:\n1. Write to the correct subdirectory: `artifacts\u002F{type-plural}\u002F` (e.g., `artifacts\u002Fprds\u002F`, `artifacts\u002Frfcs\u002F`)\n2. File naming: `{ID}-{kebab-case-slug}.md` (e.g., `PRD-001-user-authentication.md`)\n3. Run `.\u002Ftools\u002Fartifact\u002Fvalidate.sh \u003Cpath>` — fix any issues and re-validate\n\n### Step 8: Clean Up and Report\n\n1. Delete processed files from `imports\u002F` (preserve `.gitkeep`)\n2. Print a summary:\n\n```\n## Import Summary\n\n### Imported Artifacts\n| # | Source File | Type | ID | Location | Status |\n|---|------------|------|----|----------|--------|\n| 1 | auth-prd.md | prd | PRD-001 | artifacts\u002Fprds\u002FPRD-001-user-auth.md | review |\n| 2 | auth-rfc.md | rfc | RFC-001 | artifacts\u002Frfcs\u002FRFC-001-auth-service.md | review |\n\n### Relationships Created\n- PRD-001 → RFC-001 (parent → child)\n\n### Validation\nAll artifacts passed validation.\n\n### Next Steps\n1. Review each artifact — check sections marked \u003C!-- TODO -->\n2. Promote parent artifacts first: .\u002Ftools\u002Fartifact\u002Fpromote.sh \u003Cprd-path> approved\n3. Then promote children: .\u002Ftools\u002Fartifact\u002Fpromote.sh \u003Crfc-path> approved\n4. Stage gates are now active: .\u002Ftools\u002Fartifact\u002Fcheck-gate.sh \u003Cgate> \u003Cpath>\n```\n\n## Edge Cases\n\n- **Duplicate detection**: If an import matches an existing artifact (same title + type), warn before creating a duplicate\n- **Unrecognizable files**: Skip non-document files (CSV, images, binaries) with a note — suggest placing in `standards\u002F` if they're reference material\n- **Very large documents**: Proceed normally but note the size\n- **Rough notes**: Import as-is with a note: \"This appears to be rough notes. Consider expanding before promoting to `approved`.\"\n- **No files, no paste**: Print instructions for how to export from Google Docs, Notion, or Confluence\n\n## Reference\n\n- **ID**: S-ORG-05\n- **Category**: Orchestration\n- **Inputs**: files in `imports\u002F` OR inline content\n- **Outputs**: properly formatted artifacts in `artifacts\u002F` subdirectories\n- **Used by**: User (directly), Orchestrator Agent\n- **Tool scripts**: `.\u002Ftools\u002Fartifact\u002Fvalidate.sh`, `.\u002Ftools\u002Fartifact\u002Flink.sh`\n","# Artifact Import\n\nImports pre-existing documents from external sources (Google Docs, Notion, Confluence, local files, or inline-pasted content) into the Company OS artifact system with proper frontmatter, classification, and linking.\n\n## When to Use\n\n- You already have PRDs, RFCs, API specs or test plans in Google Docs, Notion, Confluence or local files.\n- You want the stage gates in `\u002Fship` to recognise that earlier work.\n- Not needed for new work: the other skills create artifacts with the right frontmatter.\n\n## Input Modes\n\n**Mode A — File-based**: User places exported documents (Markdown, HTML, or plain text) in the `imports\u002F` directory, then runs `\u002Fartifact-import`.\n\n**Mode B — Inline paste**: User pastes document content directly into the prompt (e.g., \"Import this as a PRD: [content]\"). The skill creates the artifact file from the pasted content.\n\nIf both modes are present, process both. If neither, prompt the user:\n> \"No files found in `imports\u002F` and no document content provided. Either export your docs as Markdown and place them in `imports\u002F`, or paste the content directly.\"\n\n## What You Will See\n\nBefore: a plain Markdown file you placed in `imports\u002F`.\n\n```markdown\n# User Authentication\n\n## Problem\nUsers cannot sign in with a work email.\n```\n\nAfter: the same text, with frontmatter added and the file moved to `artifacts\u002Fprds\u002FPRD-001-user-authentication.md`.\n\n```markdown\n---\nid: PRD-001\ntype: prd\ntitle: \"User Authentication\"\nstatus: review\ncreated: 2026-10-13\nauthor: imported\nparent: null\nchildren: []\ndepends_on: []\nblocks: []\ntags: [imported]\n---\n\n# User Authentication\n\n## Problem\nUsers cannot sign in with a work email.\n```\n\nIf the type is unclear, you will be asked one question and should answer with the type:\n\n```text\nI think `auth-notes.md` is an RFC, but it could also be a test plan. Which type should I assign?\n```\n\nReply `rfc` or `test-plan`. Imported files start at `review` status. You promote them to `approved` after checking them.\n\n## Procedure\n\n### Step 1: Detect and Read Sources\n\n1. Scan `imports\u002F` for any non-`.gitkeep` files\n2. Check the user's message for substantial document content (more than a few sentences of specification-like text)\n3. Read each file or inline block completely\n\n### Step 2: Classify Each Document\n\nDetermine the artifact type by analyzing content signals:\n\n| Content Signals | Artifact Type |\n|----------------|---------------|\n| Problem statement, user stories, acceptance criteria, success metrics, scope boundaries | `prd` |\n| System design, architecture, data model, modules, alternatives considered, migration plan | `rfc` |\n| API endpoints, request\u002Fresponse schemas, error codes, auth headers, pagination | `rfc` (API-focused) |\n| Test cases, test scenarios, coverage matrix, preconditions | `test-plan` |\n| Test results, pass\u002Ffail counts, regression results, coverage percentages | `qa-report` |\n| Threat model, security findings, vulnerability assessment, STRIDE analysis | `security-review` |\n| Launch plan, go-to-market, messaging, target audience, channels | `launch-brief` |\n| Decision record, ADR, rationale, alternatives considered, consequences | `decision-memo` |\n\n**Rules:**\n- If the user provides a type hint in their prompt (e.g., \"Import this PRD\"), trust the user over content analysis\n- If classification is ambiguous, ask: \"I think `filename.md` is an RFC, but it could also be a test plan. Which type should I assign?\"\n- If an API spec is imported alongside an RFC, ask: \"Embed API spec into the RFC's API Surface section, or create as a standalone artifact?\"\n\n### Step 3: Generate Artifact IDs\n\nScan `artifacts\u002F` recursively for all existing artifact IDs to find the highest number per type prefix, then auto-increment.\n\n| Type | Prefix | Example |\n|------|--------|---------|\n| prd | PRD | PRD-001 |\n| rfc | RFC | RFC-001 |\n| test-plan | TP | TP-001 |\n| qa-report | QA | QA-001 |\n| security-review | SR | SR-001 |\n| launch-brief | LB | LB-001 |\n| decision-memo | DM | DM-001 |\n\n### Step 4: Build Frontmatter\n\nGenerate complete YAML frontmatter for each artifact:\n\n```yaml\n---\nid: {generated-id}\ntype: {classified-type}\ntitle: \"{extracted-title}\"\nstatus: review\ncreated: {today or document's original date if found}\nauthor: imported\nparent: null\nchildren: []\ndepends_on: []\nblocks: []\ntags: [imported]\n---\n```\n\n**Notes:**\n- `status: review` — imported artifacts are not drafts (they already exist). Users promote to `approved` after reviewing.\n- `author: imported` — distinguishes agent-created from externally imported artifacts.\n- `tags: [imported]` — always include. Add additional tags extracted from content or context.\n- If the original document contains an author name, add as tag: `tags: [imported, author:jane-doe]`.\n\n### Step 5: Restructure Content (Best-Effort)\n\nMap imported content to Company OS templates where applicable:\n\n1. Read the relevant template if one exists (`prd-template.md` for PRDs, `rfc-template.md` for RFCs)\n2. Map imported headings to template headings (e.g., \"Goals\" → \"Success Metrics\")\n3. Preserve all original content — never delete imported text\n4. For template sections the import doesn't cover, insert the heading with: `\u003C!-- TODO: Fill in this section -->`\n5. For imported sections that don't map to the template, keep under an \"Additional Context (Imported)\" heading at the bottom\n6. For types without templates (test-plan, qa-report, security-review, launch-brief), apply frontmatter and preserve body as-is\n\n### Step 6: Detect Relationships and Link\n\nWhen multiple documents are imported together, detect relationships:\n\n1. **Explicit references**: Document mentions another artifact by name or ID\n2. **Topic coherence**: Documents about the same feature imported together are likely related\n3. **Type hierarchy**: Canonical order is PRD → RFC → test-plan\u002Fsecurity-review → qa-report → launch-brief. If multiple types are imported for the same feature, link following this hierarchy.\n4. **User hints**: If the user says \"these are all for the auth feature,\" link them as a family\n\nAfter all artifacts are written:\n- Run `.\u002Ftools\u002Fartifact\u002Flink.sh \u003Cparent-path> \u003Cchild-path>` for each detected parent-child pair\n- Run `.\u002Ftools\u002Fartifact\u002Fvalidate.sh --strict \u003Cpath>` on linked artifacts to verify bidirectional consistency\n\n### Step 7: Write Files and Validate\n\nFor each artifact:\n1. Write to the correct subdirectory: `artifacts\u002F{type-plural}\u002F` (e.g., `artifacts\u002Fprds\u002F`, `artifacts\u002Frfcs\u002F`)\n2. File naming: `{ID}-{kebab-case-slug}.md` (e.g., `PRD-001-user-authentication.md`)\n3. Run `.\u002Ftools\u002Fartifact\u002Fvalidate.sh \u003Cpath>` — fix any issues and re-validate\n\n### Step 8: Clean Up and Report\n\n1. Delete processed files from `imports\u002F` (preserve `.gitkeep`)\n2. Print a summary:\n\n```\n## Import Summary\n\n### Imported Artifacts\n| # | Source File | Type | ID | Location | Status |\n|---|------------|------|----|----------|--------|\n| 1 | auth-prd.md | prd | PRD-001 | artifacts\u002Fprds\u002FPRD-001-user-auth.md | review |\n| 2 | auth-rfc.md | rfc | RFC-001 | artifacts\u002Frfcs\u002FRFC-001-auth-service.md | review |\n\n### Relationships Created\n- PRD-001 → RFC-001 (parent → child)\n\n### Validation\nAll artifacts passed validation.\n\n### Next Steps\n1. Review each artifact — check sections marked \u003C!-- TODO -->\n2. Promote parent artifacts first: .\u002Ftools\u002Fartifact\u002Fpromote.sh \u003Cprd-path> approved\n3. Then promote children: .\u002Ftools\u002Fartifact\u002Fpromote.sh \u003Crfc-path> approved\n4. Stage gates are now active: .\u002Ftools\u002Fartifact\u002Fcheck-gate.sh \u003Cgate> \u003Cpath>\n```\n\n## Edge Cases\n\n- **Duplicate detection**: If an import matches an existing artifact (same title + type), warn before creating a duplicate\n- **Unrecognizable files**: Skip non-document files (CSV, images, binaries) with a note — suggest placing in `standards\u002F` if they're reference material\n- **Very large documents**: Proceed normally but note the size\n- **Rough notes**: Import as-is with a note: \"This appears to be rough notes. Consider expanding before promoting to `approved`.\"\n- **No files, no paste**: Print instructions for how to export from Google Docs, Notion, or Confluence\n\n## Reference\n\n- **ID**: S-ORG-05\n- **Category**: Orchestration\n- **Inputs**: files in `imports\u002F` OR inline content\n- **Outputs**: properly formatted artifacts in `artifacts\u002F` subdirectories\n- **Used by**: User (directly), Orchestrator Agent\n- **Tool scripts**: `.\u002Ftools\u002Fartifact\u002Fvalidate.sh`, `.\u002Ftools\u002Fartifact\u002Flink.sh`\n",{"name":5,"runtimes":35,"description":7},{"claude":36},{"argument-hint":37,"user-invocable":38},"\u003Cfile path or pasted content>",true,"main","e842fb6d0e04360c47db78bc2e2e2987314d64d4","os\u002Fskills\u002Fartifact-import",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":48,"prompt":58,"zipAvailable":38},[49,52,55],{"tool":50,"command":51},"npx","npx skills add vibbs\u002Fcompany-os --skill artifact-import",{"tool":53,"command":54},"bunx","bunx skills add vibbs\u002Fcompany-os --skill artifact-import",{"tool":56,"command":57},"pnpm","pnpm dlx skills add vibbs\u002Fcompany-os --skill artifact-import","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fartifact-import\u002FSKILL.md",[60,66,70,74,78,82,86],{"path":61,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":64,"sourceHtmlUrl":65},"references\u002Fadvanced.md","REFERENCE","参考文档",14034,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fbiopython\u002Freferences\u002Fadvanced.md",{"path":67,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":68,"sourceHtmlUrl":69},"references\u002Falignment.md",8954,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fbiopython\u002Freferences\u002Falignment.md",{"path":71,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":72,"sourceHtmlUrl":73},"references\u002Fblast.md",12650,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fbiopython\u002Freferences\u002Fblast.md",{"path":75,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Fdatabases.md",11507,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fbiopython\u002Freferences\u002Fdatabases.md",{"path":79,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":80,"sourceHtmlUrl":81},"references\u002Fphylogenetics.md",13836,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fbiopython\u002Freferences\u002Fphylogenetics.md",{"path":83,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":84,"sourceHtmlUrl":85},"references\u002Fsequence_io.md",7275,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fbiopython\u002Freferences\u002Fsequence_io.md",{"path":87,"resourceType":62,"resourceTypeDesc":63,"sizeBytes":88,"sourceHtmlUrl":89},"references\u002Fstructure.md",12999,"https:\u002F\u002Fgithub.com\u002FMishit18\u002Fclaude-code-templates\u002Fblob\u002Fmain\u002Fcli-tool\u002Fcomponents\u002Fskills\u002Fscientific\u002Fbiopython\u002Freferences\u002Fstructure.md",[91,100,108,118,133,151],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":97,"publishedAt":30},"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",[],[98,99],"typo field","fixture skill",{"skillNo":101,"name":102,"nameZh":6,"description":103,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":104,"categories":105,"keywords":106,"publishedAt":30},"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",[],[107,99],"spaced comments",{"skillNo":109,"name":110,"nameZh":6,"description":111,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":112,"categories":113,"keywords":114,"publishedAt":30},"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",[],[115,116,117,99],"crlf comments","CRLF","windows",{"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":30},"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",[],[125,126,23,127,128,129,99,130,131,132],"claude fields","explore","src","grep","read","Bash","code","testing",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":144,"publishedAt":30},"01M6CTH46BGKXH80RWS876Y2CW","workflow-router","Maps an objective to the artifacts, stages and agents it needs. Use when deciding what happens next or which agents to involve.","https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002Fos\u002Fskills\u002Fworkflow-router\u002FSKILL.md",[139],{"categoryNo":140,"categoryName":141,"taxonomyType":142,"taxonomyTypeDesc":143},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[145,146,147,148,149,29,150],"workflow","router","workflow router","next","maps","artifacts",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":30},"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",[],[158,159,160,148,29,161,162,163,164],"weekly review","review","priorities","health","save","support","security"]