[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K39J0XNBWBX5RHAJTAGJS2":3,"skill-same:01M6K39J0XNBWBX5RHAJTAGJS2":70},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":50,"commitSha":51,"skillDirectory":52,"forksCount":53,"repositoryHtmlUrl":54,"repositoryHomepageUrl":6,"ownerHtmlUrl":55,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":56,"install":57,"resources":69},"01M6K39J0XNBWBX5RHAJTAGJS2","architecture-diagram",null,"Use only within an active harness lifecycle when its architecture-diagram step is current. Generates and maintains C4 Mermaid diagrams; do not invoke for ordinary code changes or general architecture questions.","jstoup111\u002Fai-conductor","jstoup111","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F1585332?v=4","01M6K374Y0VEFPVCT2KPBAN4HC","James Stoup","01M6K3751X0GFKNBD0198F50XN",7,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Farchitecture-diagram\u002FSKILL.md",[],[19,20,21,22,23,24,5,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"architecture","diagram","architecture diagram","when","mermaid diagrams","invoke","changes","for","true","questions","advisory","active","do","general","diagrams","only","use","lifecycle","harness","code","mermaid","2026-11-10 10:12:30",false,"---\nname: architecture-diagram\nimplicit_invocation: required\ndescription: \"Use only within an active harness lifecycle when its architecture-diagram step is current. Generates and maintains C4 Mermaid diagrams; do not invoke for ordinary code changes or general architecture questions.\"\nenforcement: advisory\nphase: all\nstandalone: true\nrequires: []\nmodel: sonnet\n---\n\n## Purpose\n\nGenerates and maintains C4-model architecture diagrams in Mermaid-in-Markdown format.\nDiagrams live in `.docs\u002Farchitecture\u002F` and are consumed by `\u002Farchitecture-review` as input.\nThey are text-based (diffable), render natively in GitHub, and require no external tools.\n\n**Engineer validation is required** — diagrams are never auto-approved. Present them for\nreview after generation or update.\n\n## Diagram Types\n\nFive diagram types, each in its own `.md` file:\n\n| Type | File | C4 Level | Shows |\n|------|------|----------|-------|\n| System Context | `.docs\u002Farchitecture\u002Fsystem-context.md` | L1 | Users, external systems, boundaries |\n| Containers | `.docs\u002Farchitecture\u002Fcontainers.md` | L2 | App servers, databases, queues, caches |\n| Components | `.docs\u002Farchitecture\u002Fcomponents.md` | L3 | Models, services, controllers, jobs |\n| Sequences | `.docs\u002Farchitecture\u002Fsequences\u002F\u003Cflow>.md` | — | Request flows through the system |\n| ERD | `.docs\u002Farchitecture\u002Ferd.md` | — | Database tables and relationships |\n\n**L4 (code level) is intentionally omitted** — it changes too frequently to maintain and\nprovides minimal value over reading the source code directly.\n\n## Mermaid Format Convention\n\nEach diagram file follows this structure:\n\n```markdown\n# [Diagram Type]: [Project Name]\n\n**Last updated:** YYYY-MM-DD\n**Scope:** [what this diagram covers]\n\n## Diagram\n\n` ` `mermaid\n[diagram content]\n` ` `\n\n## Legend\n\n[explanation of boundaries, color coding, abbreviations]\n\n## Change Log\n\n| Date | Change | Reason |\n|------|--------|--------|\n| YYYY-MM-DD | Initial generation | Created during \u002Fbootstrap |\n```\n\nUse appropriate Mermaid diagram types:\n- System Context \u002F Containers \u002F Components → `graph TD` or `graph LR`\n- Sequences → `sequenceDiagram`\n- ERD → `erDiagram`\n\n**Placeholder notation (avoids a silent render failure).** For a variable part of a\nlabel (a slug, branch, id), use **guillemets**: `spec\u002F«slug»`, `«default»`. Do **not** use:\n- `\u003Cslug>` or the entities `<slug>` — the `>` is tokenized as an arrow and **breaks the\n  `sequenceDiagram` parser** (the whole diagram then fails to render and falls back to raw text).\n- `{slug}` — `{` starts a diamond **node** in `graph`\u002F`flowchart`, so it breaks those.\n\nGuillemets `« »` render as plain text in every Mermaid diagram type, so they are the one safe,\nconsistent choice across sequence and flowchart labels.\n\n## Practices\n\n### 1. Bootstrap Generation\n\nWhen invoked from `\u002Fbootstrap` (existing projects), scan the codebase to generate initial\ndiagrams. Use the inventory from bootstrap Step 4 — do not re-scan.\n\n**System Context (L1):**\n- Detect external APIs from: config files, environment variables, HTTP client gems\u002Fpackages\n- Detect user types from: authentication setup, role definitions\n- Detect system boundaries from: Procfile, deployment config\n\n**Containers (L2):**\n- Detect from: Procfile, docker-compose.yml, database.yml, Redis\u002Fcache config, job queue config\n- Each container gets a node with technology annotation\n\n**Components (L3):**\n- Detect from: directory structure — `app\u002Fmodels\u002F`, `app\u002Fcontrollers\u002F`, `app\u002Fservices\u002F`, `app\u002Fjobs\u002F`\n- Group by domain if module structure is apparent\n- Show dependencies between component groups\n\n**Sequences:**\n- Generate for the 3-5 most important request flows\n- Detect from: routes + controllers (highest traffic or most complex)\n- Include: HTTP request → controller → service → model → response\n\n**ERD:**\n- Generate from: model definitions (ActiveRecord associations, Prisma schema, etc.)\n- Show: tables, primary keys, foreign keys, relationship types (has_many, belongs_to, etc.)\n\nFor **new\u002Ffresh projects**, generate skeleton diagrams with placeholder components from the\nscaffold output. These populate as the design develops.\n\n**Before presenting, syntax-check every diagram.** Run\n`conduct render-diagrams --check \u003Cfile.md>...` on each file you wrote or edited. It parse-checks\nevery Mermaid block and **exits non-zero on a syntax error** (e.g. the angle-bracket trap above),\nprinting the offending file, block, and parse-error line. Fix any reported error and re-run until\nit passes **before** showing the diagrams for approval — a diagram that fails to render is not\ndone. (Interactively, if `mmdc` isn't installed this command skips with exit 0 so it never\nfalse-fails on a box without a browser.)\n\n> **This is machinery-enforced, not a reminder.** The engineer **`land` gate** re-runs the render\n> check over the spec's own authored (new\u002Fmodified) `.docs\u002F**\u002F*.md` — not the inherited `.docs\u002F`\n> history — and **fail-closed rejects the spec** if any Mermaid block does\n> not render — and, unlike the interactive command, it also rejects when diagrams are present but\n> `mmdc` is unavailable (an unvalidated diagram never lands). So a broken diagram cannot reach a\n> merged spec regardless of whether this step was run by hand. Install `@mermaid-js\u002Fmermaid-cli`\n> (a `bin\u002Finstall` mermaid preset) so the gate can validate.\n> A non-Small architecture artifact with no fenced Mermaid block is also refused at land, so an\n> ASCII sketch is not an acceptable substitute.\n\nPresent all diagrams to the engineer for validation before proceeding.\n\n> **Render diagrams for review.** When a mermaid renderer is configured (set at\n> install, stored as `mermaid_renderer` in `~\u002F.ai-conductor\u002Fconfig.yml`), the\n> engineer should review the diagrams as visuals, not raw Mermaid. Under\n> `ai-conductor` this happens automatically at the approval gate. Otherwise run\n> `conduct render-diagrams .docs\u002Farchitecture\u002F*.md` to render and open them. If no\n> renderer is configured the diagrams fall back to raw Markdown — never a blocker.\n\n### 2. Plan Update\n\nWhen invoked from `\u002Fplan` (Step 8b), read the implementation plan and stories, then\n**update the existing diagrams in place** to reflect the planned architecture. Do not\ncreate separate proposed-state files — mutate the current diagrams directly.\n\nUpdate the change log in each modified diagram file with the date and reason.\n\nPresent updated diagrams to the engineer for validation before proceeding.\n\n### 3. Post-Implementation Verification\n\nDuring `\u002Farchitecture-review` at batch boundaries, compare the current code structure\nagainst diagrams. Flag discrepancies:\n\n| Change Type | Diagram Impact |\n|-------------|---------------|\n| New model\u002Fcontroller\u002Fservice | Update component diagram |\n| New external integration | Update system context + containers |\n| New database table | Update ERD |\n| New relationship between tables | Update ERD |\n| New request flow | Add sequence diagram |\n| New background job queue | Update containers |\n\n### 4. Diagram Scope Rules\n\nNot every code change requires a diagram update. Apply these rules:\n\n**Update required:**\n- New model, controller, service, or job added\n- New external API integration\n- New database table or changed table relationships\n- New message queue or cache layer\n- New user-facing interface type\n\n**No update needed:**\n- Adding a field to an existing model (unless it changes relationships)\n- Adding a method to an existing service (unless it creates a new dependency)\n- Refactoring internals of an existing component\n- Bug fixes that don't change architecture\n- Test changes\n\n### 5. C4 Model Guidelines\n\n**Level 1 (System Context):** Show YOUR system as a single box. Show external systems,\nusers, and how they interact with your system. Keep it high-level — non-technical stakeholders\nshould understand this.\n\n**Level 2 (Containers):** Zoom into your system. Show the major runtime components: web app,\nAPI server, database, cache, job queue, etc. Each container is separately deployable.\n\n**Level 3 (Components):** Zoom into a container. Show the internal modules: models, services,\ncontrollers, jobs. Group by domain when possible.\n\n**When to stop:** L3 is usually sufficient. Only go to L4 (code) for genuinely complex\nalgorithms or state machines that benefit from a visual representation — and even then,\nprefer a sequence diagram over a class diagram.\n\n### 6. Large Diagram Handling\n\nIf a component or ERD diagram becomes too large to render cleanly (>30 nodes), split it\ninto sub-diagrams by domain boundary:\n\n```\n.docs\u002Farchitecture\u002Fcomponents.md           → overview (domain groups as single nodes)\n.docs\u002Farchitecture\u002Fcomponents-auth.md      → auth domain detail\n.docs\u002Farchitecture\u002Fcomponents-billing.md   → billing domain detail\n```\n\nReference the overview diagram from the detail diagrams and vice versa.\n\n## Output\n\nGenerated files:\n- `.docs\u002Farchitecture\u002Fsystem-context.md`\n- `.docs\u002Farchitecture\u002Fcontainers.md`\n- `.docs\u002Farchitecture\u002Fcomponents.md`\n- `.docs\u002Farchitecture\u002Fsequences\u002F\u003Cflow-name>.md` (one per flow)\n- `.docs\u002Farchitecture\u002Ferd.md`\n\n## Verification\n\n- [ ] System context diagram reflects all external systems and user types\n- [ ] Container diagram shows all major runtime components\n- [ ] Component diagram covers models, services, controllers, jobs\n- [ ] ERD matches current schema (tables, relationships, key columns)\n- [ ] Sequence diagrams cover 3-5 primary request flows\n- [ ] All diagrams use valid Mermaid syntax in `.md` files\n- [ ] Diagrams stored in `.docs\u002Farchitecture\u002F`\n- [ ] Change log updated when diagrams are modified\n- [ ] Engineer validation requested and received\n","## Purpose\n\nGenerates and maintains C4-model architecture diagrams in Mermaid-in-Markdown format.\nDiagrams live in `.docs\u002Farchitecture\u002F` and are consumed by `\u002Farchitecture-review` as input.\nThey are text-based (diffable), render natively in GitHub, and require no external tools.\n\n**Engineer validation is required** — diagrams are never auto-approved. Present them for\nreview after generation or update.\n\n## Diagram Types\n\nFive diagram types, each in its own `.md` file:\n\n| Type | File | C4 Level | Shows |\n|------|------|----------|-------|\n| System Context | `.docs\u002Farchitecture\u002Fsystem-context.md` | L1 | Users, external systems, boundaries |\n| Containers | `.docs\u002Farchitecture\u002Fcontainers.md` | L2 | App servers, databases, queues, caches |\n| Components | `.docs\u002Farchitecture\u002Fcomponents.md` | L3 | Models, services, controllers, jobs |\n| Sequences | `.docs\u002Farchitecture\u002Fsequences\u002F\u003Cflow>.md` | — | Request flows through the system |\n| ERD | `.docs\u002Farchitecture\u002Ferd.md` | — | Database tables and relationships |\n\n**L4 (code level) is intentionally omitted** — it changes too frequently to maintain and\nprovides minimal value over reading the source code directly.\n\n## Mermaid Format Convention\n\nEach diagram file follows this structure:\n\n```markdown\n# [Diagram Type]: [Project Name]\n\n**Last updated:** YYYY-MM-DD\n**Scope:** [what this diagram covers]\n\n## Diagram\n\n` ` `mermaid\n[diagram content]\n` ` `\n\n## Legend\n\n[explanation of boundaries, color coding, abbreviations]\n\n## Change Log\n\n| Date | Change | Reason |\n|------|--------|--------|\n| YYYY-MM-DD | Initial generation | Created during \u002Fbootstrap |\n```\n\nUse appropriate Mermaid diagram types:\n- System Context \u002F Containers \u002F Components → `graph TD` or `graph LR`\n- Sequences → `sequenceDiagram`\n- ERD → `erDiagram`\n\n**Placeholder notation (avoids a silent render failure).** For a variable part of a\nlabel (a slug, branch, id), use **guillemets**: `spec\u002F«slug»`, `«default»`. Do **not** use:\n- `\u003Cslug>` or the entities `<slug>` — the `>` is tokenized as an arrow and **breaks the\n  `sequenceDiagram` parser** (the whole diagram then fails to render and falls back to raw text).\n- `{slug}` — `{` starts a diamond **node** in `graph`\u002F`flowchart`, so it breaks those.\n\nGuillemets `« »` render as plain text in every Mermaid diagram type, so they are the one safe,\nconsistent choice across sequence and flowchart labels.\n\n## Practices\n\n### 1. Bootstrap Generation\n\nWhen invoked from `\u002Fbootstrap` (existing projects), scan the codebase to generate initial\ndiagrams. Use the inventory from bootstrap Step 4 — do not re-scan.\n\n**System Context (L1):**\n- Detect external APIs from: config files, environment variables, HTTP client gems\u002Fpackages\n- Detect user types from: authentication setup, role definitions\n- Detect system boundaries from: Procfile, deployment config\n\n**Containers (L2):**\n- Detect from: Procfile, docker-compose.yml, database.yml, Redis\u002Fcache config, job queue config\n- Each container gets a node with technology annotation\n\n**Components (L3):**\n- Detect from: directory structure — `app\u002Fmodels\u002F`, `app\u002Fcontrollers\u002F`, `app\u002Fservices\u002F`, `app\u002Fjobs\u002F`\n- Group by domain if module structure is apparent\n- Show dependencies between component groups\n\n**Sequences:**\n- Generate for the 3-5 most important request flows\n- Detect from: routes + controllers (highest traffic or most complex)\n- Include: HTTP request → controller → service → model → response\n\n**ERD:**\n- Generate from: model definitions (ActiveRecord associations, Prisma schema, etc.)\n- Show: tables, primary keys, foreign keys, relationship types (has_many, belongs_to, etc.)\n\nFor **new\u002Ffresh projects**, generate skeleton diagrams with placeholder components from the\nscaffold output. These populate as the design develops.\n\n**Before presenting, syntax-check every diagram.** Run\n`conduct render-diagrams --check \u003Cfile.md>...` on each file you wrote or edited. It parse-checks\nevery Mermaid block and **exits non-zero on a syntax error** (e.g. the angle-bracket trap above),\nprinting the offending file, block, and parse-error line. Fix any reported error and re-run until\nit passes **before** showing the diagrams for approval — a diagram that fails to render is not\ndone. (Interactively, if `mmdc` isn't installed this command skips with exit 0 so it never\nfalse-fails on a box without a browser.)\n\n> **This is machinery-enforced, not a reminder.** The engineer **`land` gate** re-runs the render\n> check over the spec's own authored (new\u002Fmodified) `.docs\u002F**\u002F*.md` — not the inherited `.docs\u002F`\n> history — and **fail-closed rejects the spec** if any Mermaid block does\n> not render — and, unlike the interactive command, it also rejects when diagrams are present but\n> `mmdc` is unavailable (an unvalidated diagram never lands). So a broken diagram cannot reach a\n> merged spec regardless of whether this step was run by hand. Install `@mermaid-js\u002Fmermaid-cli`\n> (a `bin\u002Finstall` mermaid preset) so the gate can validate.\n> A non-Small architecture artifact with no fenced Mermaid block is also refused at land, so an\n> ASCII sketch is not an acceptable substitute.\n\nPresent all diagrams to the engineer for validation before proceeding.\n\n> **Render diagrams for review.** When a mermaid renderer is configured (set at\n> install, stored as `mermaid_renderer` in `~\u002F.ai-conductor\u002Fconfig.yml`), the\n> engineer should review the diagrams as visuals, not raw Mermaid. Under\n> `ai-conductor` this happens automatically at the approval gate. Otherwise run\n> `conduct render-diagrams .docs\u002Farchitecture\u002F*.md` to render and open them. If no\n> renderer is configured the diagrams fall back to raw Markdown — never a blocker.\n\n### 2. Plan Update\n\nWhen invoked from `\u002Fplan` (Step 8b), read the implementation plan and stories, then\n**update the existing diagrams in place** to reflect the planned architecture. Do not\ncreate separate proposed-state files — mutate the current diagrams directly.\n\nUpdate the change log in each modified diagram file with the date and reason.\n\nPresent updated diagrams to the engineer for validation before proceeding.\n\n### 3. Post-Implementation Verification\n\nDuring `\u002Farchitecture-review` at batch boundaries, compare the current code structure\nagainst diagrams. Flag discrepancies:\n\n| Change Type | Diagram Impact |\n|-------------|---------------|\n| New model\u002Fcontroller\u002Fservice | Update component diagram |\n| New external integration | Update system context + containers |\n| New database table | Update ERD |\n| New relationship between tables | Update ERD |\n| New request flow | Add sequence diagram |\n| New background job queue | Update containers |\n\n### 4. Diagram Scope Rules\n\nNot every code change requires a diagram update. Apply these rules:\n\n**Update required:**\n- New model, controller, service, or job added\n- New external API integration\n- New database table or changed table relationships\n- New message queue or cache layer\n- New user-facing interface type\n\n**No update needed:**\n- Adding a field to an existing model (unless it changes relationships)\n- Adding a method to an existing service (unless it creates a new dependency)\n- Refactoring internals of an existing component\n- Bug fixes that don't change architecture\n- Test changes\n\n### 5. C4 Model Guidelines\n\n**Level 1 (System Context):** Show YOUR system as a single box. Show external systems,\nusers, and how they interact with your system. Keep it high-level — non-technical stakeholders\nshould understand this.\n\n**Level 2 (Containers):** Zoom into your system. Show the major runtime components: web app,\nAPI server, database, cache, job queue, etc. Each container is separately deployable.\n\n**Level 3 (Components):** Zoom into a container. Show the internal modules: models, services,\ncontrollers, jobs. Group by domain when possible.\n\n**When to stop:** L3 is usually sufficient. Only go to L4 (code) for genuinely complex\nalgorithms or state machines that benefit from a visual representation — and even then,\nprefer a sequence diagram over a class diagram.\n\n### 6. Large Diagram Handling\n\nIf a component or ERD diagram becomes too large to render cleanly (>30 nodes), split it\ninto sub-diagrams by domain boundary:\n\n```\n.docs\u002Farchitecture\u002Fcomponents.md           → overview (domain groups as single nodes)\n.docs\u002Farchitecture\u002Fcomponents-auth.md      → auth domain detail\n.docs\u002Farchitecture\u002Fcomponents-billing.md   → billing domain detail\n```\n\nReference the overview diagram from the detail diagrams and vice versa.\n\n## Output\n\nGenerated files:\n- `.docs\u002Farchitecture\u002Fsystem-context.md`\n- `.docs\u002Farchitecture\u002Fcontainers.md`\n- `.docs\u002Farchitecture\u002Fcomponents.md`\n- `.docs\u002Farchitecture\u002Fsequences\u002F\u003Cflow-name>.md` (one per flow)\n- `.docs\u002Farchitecture\u002Ferd.md`\n\n## Verification\n\n- [ ] System context diagram reflects all external systems and user types\n- [ ] Container diagram shows all major runtime components\n- [ ] Component diagram covers models, services, controllers, jobs\n- [ ] ERD matches current schema (tables, relationships, key columns)\n- [ ] Sequence diagrams cover 3-5 primary request flows\n- [ ] All diagrams use valid Mermaid syntax in `.md` files\n- [ ] Diagrams stored in `.docs\u002Farchitecture\u002F`\n- [ ] Change log updated when diagrams are modified\n- [ ] Engineer validation requested and received\n",{"name":5,"model":45,"phase":46,"requires":47,"standalone":48,"description":7,"enforcement":29,"implicit_invocation":49},"sonnet","all",[],true,"required","main","136b34ec6792f53d0beba330dfa2dffad6c93484","skills\u002Farchitecture-diagram",2,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor","https:\u002F\u002Fgithub.com\u002Fjstoup111","2026-11-11 22:26:29",{"source":8,"skillName":5,"commands":58,"prompt":68,"zipAvailable":48},[59,62,65],{"tool":60,"command":61},"npx","npx skills add jstoup111\u002Fai-conductor --skill architecture-diagram",{"tool":63,"command":64},"bunx","bunx skills add jstoup111\u002Fai-conductor --skill architecture-diagram",{"tool":66,"command":67},"pnpm","pnpm dlx skills add jstoup111\u002Fai-conductor --skill architecture-diagram","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Farchitecture-diagram\u002FSKILL.md",[],[71,90,129,147,166,181],{"skillNo":72,"name":73,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":40},"01M70YKSA2H7Q9WSRD1ECEGY20","build-review-dependency-hygiene","Judge whether a feature diff adds unnecessary, insufficiently pinned, or license-incompatible dependencies.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fbuild-review-dependency-hygiene\u002FSKILL.md",[],[78,79,80,81,82,83,84,85,86,87,27,88,89],"build","dependency hygiene","dependency","hygiene","build review dependency hygiene","review","feature","diff","dependencies","license","judge","gating",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":109,"publishedAt":40},"01M6K3EQQ6ADH3G2RMYK6XE26E","writing-system-tests","Use BEFORE implementing any feature that has stories in .docs\u002Fstories\u002F — generates failing acceptance specs from acceptance criteria as the RED phase of TDD. Generates HTTP\u002Frequest-level acceptance tests for headless\u002FAPI projects, end-to-end UI tests for projects with a frontend, using the project's own test framework and directory conventions.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fwriting-system-tests\u002FSKILL.md",[96,101,104],{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":102,"categoryName":103,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":105,"categoryName":106,"taxonomyType":107,"taxonomyTypeDesc":108},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[110,111,112,113,114,115,116,117,118,119,120,121,122,123,124,125,126,89,127,128],"writing","system","tests","writing system tests","projects","headless","project","end","implementing","frontend","acceptance","api","claims","directory","ui","framework","failing","phase","request",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":135,"publishedAt":40},"01M6K3EHR0QQ1QY1S9RC6D1WTD","verify-claims","Use only when an active workflow is about to rely on a nontrivial factual claim or assumption for a spec, plan, ADR, finding, or code decision. Do not invoke for casual questions, status reports, restatements, or trivially verifiable mechanics.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fverify-claims\u002FSKILL.md",[],[136,122,137,31,138,26,139,140,27,141,34,35,142,38,143,144,30,28,145,146,24,89,22],"verify claims","verify","adr","decision","claim","mechanics","workflow","reports","plan","about","spec",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":40},"01M6K3ED4NF5DJA2Y35MH2JCRC","tdd","Use when implementing any feature or bugfix. Five-step cycle: RED → DOMAIN → GREEN → DOMAIN → COMMIT. Enforces test-first development with domain integrity review at every phase boundary.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[],[149,154,155,156,118,157,83,158,159,160,161,84,162,27,35,163,164,165,22,127],"green","cycle","structural","commit","at","bugfix","integrity","domain","development","with","test","test-first",{"skillNo":167,"name":168,"nameZh":6,"description":169,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":170,"categories":171,"keywords":172,"publishedAt":40},"01M6K3E6PEXBXYY2K8TSRTN1JT","stories","Use only within active engineer\u002Fconduct DECIDE after architecture approval, when a committed `.docs\u002Fstories` acceptance artifact is required. Do not invoke for general user-story examples, requirements discussion, or direct implementation requests.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fstories\u002FSKILL.md",[],[168,173,31,26,174,175,32,27,34,35,120,176,19,177,122,178,137,179,30,180,24,89,22],"conduct","decide","engineer","requirements","examples","artifact","requests","implementation",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":187,"publishedAt":40},"01M6K3E1HE7267YKFJQ3YFCGW5","stack-land","Use when an operator needs to land reviewed manual changes on the correct closed child of a stacked feature. Operator-invoked only: inspect ownership, propose the safe child with evidence, and require confirmation before opening the landing.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fstack-land\u002FSKILL.md",[],[188,189,190,163,122,191,192,25,137,84,193,194,195,196,197,27,198,34,35,199,22,29],"stack","land","stack land","evidence","child","inspect","manual","correct","landing","safe","operator","confirmation"]