[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6CT70CAR2WH2NVFSZCS1BMC":3,"skill-same:01M6CT70CAR2WH2NVFSZCS1BMC":83},{"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":31,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":56,"commitSha":57,"skillDirectory":58,"forksCount":59,"repositoryHtmlUrl":60,"repositoryHomepageUrl":6,"ownerHtmlUrl":61,"ownerBlogUrl":6,"ownerDescription":62,"updatedAt":63,"install":64,"resources":76},"01M6CT70CAR2WH2NVFSZCS1BMC","architecture-draft",null,"Writes a technical design doc (RFC) covering system boundaries, modules, data model and integrations. Use when turning a PRD into a design or making an architecture decision.","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\u002F.claude\u002Fskills\u002Farchitecture-draft\u002FSKILL.md",[18,23,28],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000031","产品经理","PROFESSION","适用职业",{"categoryNo":29,"categoryName":30,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"architecture","architecture draft","draft","data","doc","system","RFC","design doc","model","integrations","decision","technical","use","modules","technical design","prd","design","2026-11-10 10:12:30",false,"---\nname: architecture-draft\ndescription: Writes a technical design doc (RFC) covering system boundaries, modules, data model and integrations. Use when turning a PRD into a design or making an architecture decision.\nuser-invocable: true\nargument-hint: \"\u003CPRD ID or feature to design>\"\n---\n\n# Architecture Draft (SaaS Core)\n\n## Reference\n- **ID**: S-ENG-01\n- **Category**: Engineering\n- **Inputs**: approved PRD, company.config.yaml, existing RFCs, standards\u002Fapi\u002F and standards\u002Fcoding\u002F\n- **Outputs**: RFC artifact → artifacts\u002Frfcs\u002F\n- **Used by**: Engineering Agent\n- **Tool scripts**: .\u002Ftools\u002Fartifact\u002Fvalidate.sh, .\u002Ftools\u002Fci\u002Fopenapi-lint.sh, .\u002Ftools\u002Fdb\u002Fmigration-check.sh\n\nFor the RFC artifact template, see [rfc-template.md](rfc-template.md).\n\n## Purpose\n\nTranslate an approved PRD into a technical design document (RFC\u002FADR) that defines how the feature will be built. The RFC bridges product intent and code — it's the \"how\" to the PRD's \"what.\"\n\n## When to Use\n\n- Approved PRD requires technical design\n- Significant architectural change or new system component\n- Cross-cutting concern that affects multiple modules\n\n## Architecture Drafting Procedure\n\n### Step 1: Load Context\n\nBefore designing anything:\n\n1. **Read the PRD** — understand every acceptance criterion\n2. **Read `company.config.yaml`** — understand tech stack constraints\n3. **Read existing RFCs** in `artifacts\u002Frfcs\u002F` — understand architectural precedent\n4. **Read standards** in `standards\u002Fapi\u002F` and `standards\u002Fcoding\u002F`\n5. **Check for related artifacts** — is there an existing data model, auth system, or API pattern to extend?\n\n### Step 2: Tech Stack Fitness Check\n\nEvaluate whether the configured tech stack is well-suited for this feature:\n\n| Aspect | Check |\n|--------|-------|\n| **Language\u002FFramework** | Can the framework handle this pattern natively? |\n| **Database** | Is the data model relational, document, or graph? Does the configured DB fit? |\n| **Queue\u002FBackground** | Does this need async processing? Is the configured queue sufficient? |\n| **Scale** | Will this work at the expected load? |\n\n**If the stack is suboptimal**: Document the concern explicitly in the RFC's \"Alternatives Considered\" section. Recommend an alternative with tradeoffs. But respect the user's final decision.\n\n**Library documentation**: Before committing to any library or framework in the design, fetch its current documentation via Context7 (`resolve-library-id` → `query-docs`). Verify the APIs and patterns you plan to use actually exist in the current version. This prevents designing around deprecated or non-existent features.\n\n### Step 3: Define System Boundaries\n\nDraw the boundary between what's new, what's extended, and what's external. Use the **excalidraw skill** (S-ENG-17) to produce the system architecture diagram — Mermaid `graph TD` inline in the RFC and optionally an Excalidraw file for richer documentation.\n\n```\n[Client] → [API Layer] → [Service Layer] → [Data Layer]\n                              ↓\n                        [Queue \u002F Jobs]\n                              ↓\n                      [External Services]\n```\n\nFor each boundary, define: interface, protocol, and auth.\n\n### Step 4: Design the Data Model\n\n1. **Identify entities** — what domain objects does this feature need?\n2. **Define relationships** — one-to-one, one-to-many, many-to-many\n3. **Apply multi-tenancy** — if configured, apply tenant scoping\n4. **Plan migrations** — new tables, columns, indexes; consider rollback strategy\n\n### Step 5: Design API Surface\n\nBased on `api.*` config, define endpoints, request\u002Fresponse shapes, error handling, auth, pagination, and validation. Produce OpenAPI spec if configured. Validate with `.\u002Ftools\u002Fci\u002Fopenapi-lint.sh`.\n\n### Step 6: Design Service Layer\n\nDefine business logic, transaction boundaries, error handling, side effects, and background jobs.\n\n### Step 7: Address Cross-Cutting Concerns\n\n| Concern | How Addressed |\n|---------|---------------|\n| **Auth & Permissions** | [describe] |\n| **Multi-tenancy** | [describe or reference multi-tenancy skill] |\n| **Observability** | [describe or reference observability-baseline skill] |\n| **Caching** | [describe strategy, invalidation] |\n| **Rate limiting** | [describe if applicable] |\n| **i18n** | [string management, locale detection, fallback — or \"N\u002FA\" if not enabled] |\n| **Deployment Strategy** | [environment ladder, rollout approach, rollback procedure — reference deployment-strategy skill] |\n| **Feature Flags** | [flag specifications for new features, progressive discovery levels — reference feature-flags skill] |\n| **Platform Strategy** | [responsive web, native mobile, PWA considerations — reference mobile-readiness skill if `platforms.targets` configured] |\n\n### Step 8: Assemble the RFC\n\nUse the template in [rfc-template.md](rfc-template.md).\n\n### Step 9: Validate\n\n- [ ] RFC addresses every PRD acceptance criterion\n- [ ] Data model is consistent with existing schema\n- [ ] API design follows configured standards\n- [ ] Multi-tenancy applied if configured\n- [ ] Observability hooks defined\n- [ ] Migration strategy is safe (can rollback)\n- [ ] Alternatives documented with rationale\n- [ ] OpenAPI spec validates if applicable\n- [ ] Deployment strategy section included (references deployment-strategy skill)\n- [ ] Feature flag strategy addressed (if applicable)\n- [ ] Platform targets accounted for (responsive, native, PWA)\n- [ ] Artifact frontmatter is complete (`.\u002Ftools\u002Fartifact\u002Fvalidate.sh`)\n\n### Step 10: Handoff\n\n1. Set status to `review`\n2. Store in `artifacts\u002Frfcs\u002F`\n3. Notify Orchestrator — RFC ready for Ops & Risk review and QA test planning\n4. After approval, proceed with implementation (implementation-decomposer)\n\n## Import Variant\n\nIf an RFC or architecture document already exists outside Company OS, use `\u002Fartifact-import` instead of creating from scratch. The import skill classifies the document, applies the RFC template structure, generates frontmatter, and links it to its parent PRD if one exists. After import, review against this skill's quality checklist and ensure tech stack fitness is evaluated.\n\n## Quality Checklist\n\n- [ ] Every PRD acceptance criterion has a technical solution\n- [ ] Tech stack fitness evaluated and concerns flagged\n- [ ] Data model is normalized appropriately\n- [ ] API follows configured conventions\n- [ ] Cross-cutting concerns addressed (not deferred)\n- [ ] Migration strategy allows safe rollback\n- [ ] At least one alternative considered\n- [ ] RFC is implementable by someone who hasn't read the PRD\n","# Architecture Draft (SaaS Core)\n\n## Reference\n- **ID**: S-ENG-01\n- **Category**: Engineering\n- **Inputs**: approved PRD, company.config.yaml, existing RFCs, standards\u002Fapi\u002F and standards\u002Fcoding\u002F\n- **Outputs**: RFC artifact → artifacts\u002Frfcs\u002F\n- **Used by**: Engineering Agent\n- **Tool scripts**: .\u002Ftools\u002Fartifact\u002Fvalidate.sh, .\u002Ftools\u002Fci\u002Fopenapi-lint.sh, .\u002Ftools\u002Fdb\u002Fmigration-check.sh\n\nFor the RFC artifact template, see [rfc-template.md](rfc-template.md).\n\n## Purpose\n\nTranslate an approved PRD into a technical design document (RFC\u002FADR) that defines how the feature will be built. The RFC bridges product intent and code — it's the \"how\" to the PRD's \"what.\"\n\n## When to Use\n\n- Approved PRD requires technical design\n- Significant architectural change or new system component\n- Cross-cutting concern that affects multiple modules\n\n## Architecture Drafting Procedure\n\n### Step 1: Load Context\n\nBefore designing anything:\n\n1. **Read the PRD** — understand every acceptance criterion\n2. **Read `company.config.yaml`** — understand tech stack constraints\n3. **Read existing RFCs** in `artifacts\u002Frfcs\u002F` — understand architectural precedent\n4. **Read standards** in `standards\u002Fapi\u002F` and `standards\u002Fcoding\u002F`\n5. **Check for related artifacts** — is there an existing data model, auth system, or API pattern to extend?\n\n### Step 2: Tech Stack Fitness Check\n\nEvaluate whether the configured tech stack is well-suited for this feature:\n\n| Aspect | Check |\n|--------|-------|\n| **Language\u002FFramework** | Can the framework handle this pattern natively? |\n| **Database** | Is the data model relational, document, or graph? Does the configured DB fit? |\n| **Queue\u002FBackground** | Does this need async processing? Is the configured queue sufficient? |\n| **Scale** | Will this work at the expected load? |\n\n**If the stack is suboptimal**: Document the concern explicitly in the RFC's \"Alternatives Considered\" section. Recommend an alternative with tradeoffs. But respect the user's final decision.\n\n**Library documentation**: Before committing to any library or framework in the design, fetch its current documentation via Context7 (`resolve-library-id` → `query-docs`). Verify the APIs and patterns you plan to use actually exist in the current version. This prevents designing around deprecated or non-existent features.\n\n### Step 3: Define System Boundaries\n\nDraw the boundary between what's new, what's extended, and what's external. Use the **excalidraw skill** (S-ENG-17) to produce the system architecture diagram — Mermaid `graph TD` inline in the RFC and optionally an Excalidraw file for richer documentation.\n\n```\n[Client] → [API Layer] → [Service Layer] → [Data Layer]\n                              ↓\n                        [Queue \u002F Jobs]\n                              ↓\n                      [External Services]\n```\n\nFor each boundary, define: interface, protocol, and auth.\n\n### Step 4: Design the Data Model\n\n1. **Identify entities** — what domain objects does this feature need?\n2. **Define relationships** — one-to-one, one-to-many, many-to-many\n3. **Apply multi-tenancy** — if configured, apply tenant scoping\n4. **Plan migrations** — new tables, columns, indexes; consider rollback strategy\n\n### Step 5: Design API Surface\n\nBased on `api.*` config, define endpoints, request\u002Fresponse shapes, error handling, auth, pagination, and validation. Produce OpenAPI spec if configured. Validate with `.\u002Ftools\u002Fci\u002Fopenapi-lint.sh`.\n\n### Step 6: Design Service Layer\n\nDefine business logic, transaction boundaries, error handling, side effects, and background jobs.\n\n### Step 7: Address Cross-Cutting Concerns\n\n| Concern | How Addressed |\n|---------|---------------|\n| **Auth & Permissions** | [describe] |\n| **Multi-tenancy** | [describe or reference multi-tenancy skill] |\n| **Observability** | [describe or reference observability-baseline skill] |\n| **Caching** | [describe strategy, invalidation] |\n| **Rate limiting** | [describe if applicable] |\n| **i18n** | [string management, locale detection, fallback — or \"N\u002FA\" if not enabled] |\n| **Deployment Strategy** | [environment ladder, rollout approach, rollback procedure — reference deployment-strategy skill] |\n| **Feature Flags** | [flag specifications for new features, progressive discovery levels — reference feature-flags skill] |\n| **Platform Strategy** | [responsive web, native mobile, PWA considerations — reference mobile-readiness skill if `platforms.targets` configured] |\n\n### Step 8: Assemble the RFC\n\nUse the template in [rfc-template.md](rfc-template.md).\n\n### Step 9: Validate\n\n- [ ] RFC addresses every PRD acceptance criterion\n- [ ] Data model is consistent with existing schema\n- [ ] API design follows configured standards\n- [ ] Multi-tenancy applied if configured\n- [ ] Observability hooks defined\n- [ ] Migration strategy is safe (can rollback)\n- [ ] Alternatives documented with rationale\n- [ ] OpenAPI spec validates if applicable\n- [ ] Deployment strategy section included (references deployment-strategy skill)\n- [ ] Feature flag strategy addressed (if applicable)\n- [ ] Platform targets accounted for (responsive, native, PWA)\n- [ ] Artifact frontmatter is complete (`.\u002Ftools\u002Fartifact\u002Fvalidate.sh`)\n\n### Step 10: Handoff\n\n1. Set status to `review`\n2. Store in `artifacts\u002Frfcs\u002F`\n3. Notify Orchestrator — RFC ready for Ops & Risk review and QA test planning\n4. After approval, proceed with implementation (implementation-decomposer)\n\n## Import Variant\n\nIf an RFC or architecture document already exists outside Company OS, use `\u002Fartifact-import` instead of creating from scratch. The import skill classifies the document, applies the RFC template structure, generates frontmatter, and links it to its parent PRD if one exists. After import, review against this skill's quality checklist and ensure tech stack fitness is evaluated.\n\n## Quality Checklist\n\n- [ ] Every PRD acceptance criterion has a technical solution\n- [ ] Tech stack fitness evaluated and concerns flagged\n- [ ] Data model is normalized appropriately\n- [ ] API follows configured conventions\n- [ ] Cross-cutting concerns addressed (not deferred)\n- [ ] Migration strategy allows safe rollback\n- [ ] At least one alternative considered\n- [ ] RFC is implementable by someone who hasn't read the PRD\n",{"name":5,"description":7,"argument-hint":54,"user-invocable":55},"\u003CPRD ID or feature to design>",true,"main","e842fb6d0e04360c47db78bc2e2e2987314d64d4",".claude\u002Fskills\u002Farchitecture-draft",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":65,"prompt":75,"zipAvailable":55},[66,69,72],{"tool":67,"command":68},"npx","npx skills add vibbs\u002Fcompany-os --skill architecture-draft",{"tool":70,"command":71},"bunx","bunx skills add vibbs\u002Fcompany-os --skill architecture-draft",{"tool":73,"command":74},"pnpm","pnpm dlx skills add vibbs\u002Fcompany-os --skill architecture-draft","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Farchitecture-draft\u002FSKILL.md",[77],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},"rfc-template.md","REFERENCE","参考文档",1348,"https:\u002F\u002Fgithub.com\u002Fvibbs\u002Fcompany-os\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Farchitecture-draft\u002Frfc-template.md",[84,93,101,111,127,143],{"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":49},"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",[],[91,92],"typo field","fixture skill",{"skillNo":94,"name":95,"nameZh":6,"description":96,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":97,"categories":98,"keywords":99,"publishedAt":49},"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",[],[100,92],"spaced comments",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":49},"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",[],[108,109,110,92],"crlf comments","CRLF","windows",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":49},"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",[],[118,119,120,121,122,123,92,124,125,126],"claude fields","explore","documents","src","grep","read","Bash","code","testing",{"skillNo":128,"name":129,"nameZh":6,"description":130,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":131,"categories":132,"keywords":136,"publishedAt":49},"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",[133],{"categoryNo":134,"categoryName":135,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[137,138,139,140,141,44,142],"workflow","router","workflow router","next","maps","artifacts",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":49},"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",[],[150,151,152,140,44,153,154,155,156],"weekly review","review","priorities","health","save","support","security"]