[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K39VS153HZXNH9XMNWACKX":3,"skill-same:01M6K39VS153HZXNH9XMNWACKX":81},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":55,"install":56,"resources":68},"01M6K39VS153HZXNH9XMNWACKX","assess",null,"Use for codebase health assessment. Dispatches 9 specialist agents + CTO orchestrator to evaluate security, data integrity, dependencies, architecture, duplication, testing, infrastructure, observability, and developer experience.","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\u002Fassess\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"advisory","specialist","evaluate","codebase","for","claims","cto","true","health assessment","data integrity","testing","dependencies","codebase health","use","orchestrator","health","verify","observability","assessment","architecture","2026-11-10 10:12:30",false,"---\nname: assess\ndisable-model-invocation: true\ndescription: \"Use for codebase health assessment. Dispatches 9 specialist agents + CTO orchestrator to evaluate security, data integrity, dependencies, architecture, duplication, testing, infrastructure, observability, and developer experience.\"\nenforcement: advisory\nphase: understand\nstandalone: true\nrequires: [verify-claims]\nmodel: sonnet\n---\n\n## Purpose\n\nPerforms a comprehensive technical assessment of a codebase using 9 specialist agents that each\ndeeply evaluate one dimension of code health, followed by a CTO orchestrator that synthesizes\nfindings into a prioritized report with opinionated recommendations.\n\n**Correctness gate:** every finding is a claim about the codebase. Per the `\u002Fverify-claims`\nprotocol, each specialist finding carries a grounded confidence % and its basis (`verified` — you\nobserved it in the code — vs `inferred`), never asserts a finding it has not verified, and marks a\nlow-confidence judgment as **tentative** rather than stating it as fact. The CTO orchestrator must\nnot raise a finding's confidence beyond what its evidence supports when prioritizing.\n\n### Provider-native delegation\n\nDispatch each specialist through the selected host's available subagent facility. Preserve the\nspecialist persona, fresh assessment context, report output, and the assessment gates regardless\nof host. **Claude delegation:** Claude uses the Agent tool; the Claude model names below apply\nonly to that facility. A Codex-selected run uses its available subagent facility and configured\nCodex provider policy, without translating Claude model names.\n\n**Invocation:**\n- **Onboarding:** Runs as part of `\u002Fconduct` after bootstrap for existing projects\n- **On-demand:** User invokes `\u002Fassess` anytime for a health check\n- **Selective:** `\u002Fassess --area security` runs only the security specialist\n\n## Practices\n\n### 1. Determine Scope\n\nCheck invocation arguments:\n\n| Argument | Behavior |\n|----------|----------|\n| _(none)_ | Full assessment — all 9 specialists + CTO synthesis |\n| `--area \u003Cname>` | Single specialist only (security, data-integrity, dependencies, architecture, duplication, testing, infrastructure, observability, devex) |\n\n### 2. Prepare Assessment Directory\n\nCreate `.pipeline\u002Fassessment\u002F` if it doesn't exist. Clear any stale reports from previous runs.\n\n### 3. Gather Shared Context\n\nBefore dispatching specialists, gather context they all need:\n\n1. **Codebase file listing** — `find . -type f` filtered to source\u002Fconfig files (exclude vendor, node_modules, .git, tmp, log)\n2. **Tech-context** — if loaded in session from `\u002Fbootstrap`, include it\n3. **Existing decisions** — list files in `.docs\u002Fdecisions\u002F` so architecture specialist can cross-reference\n\n### 4. Dispatch Specialists (3 Batches of 3)\n\nDispatch specialists in parallel within each batch, sequential between batches.\nEach specialist is a subagent using the corresponding agent persona.\n\n**Batch 1** (parallel):\n\n| Specialist | Agent File | Claude model | Output |\n|-----------|-----------|-------|--------|\n| Security Auditor | `agents\u002Fcto-security.md` | opus | `.pipeline\u002Fassessment\u002Fcto-security.md` |\n| Data Integrity Reviewer | `agents\u002Fcto-data-integrity.md` | opus | `.pipeline\u002Fassessment\u002Fcto-data-integrity.md` |\n| Dependency Auditor | `agents\u002Fcto-dependencies.md` | sonnet | `.pipeline\u002Fassessment\u002Fcto-dependencies.md` |\n\n**Rate limit cooldown: sleep 30 seconds before dispatching Batch 2.**\n\n**Batch 2** (parallel, after Batch 1 completes):\n\n| Specialist | Agent File | Claude model | Output |\n|-----------|-----------|-------|--------|\n| Architecture Coherence | `agents\u002Fcto-architecture.md` | opus | `.pipeline\u002Fassessment\u002Fcto-architecture.md` |\n| Code Duplication | `agents\u002Fcto-duplication.md` | sonnet | `.pipeline\u002Fassessment\u002Fcto-duplication.md` |\n| Test Strategy | `agents\u002Fcto-testing.md` | sonnet | `.pipeline\u002Fassessment\u002Fcto-testing.md` |\n\n**Rate limit cooldown: sleep 30 seconds before dispatching Batch 3.**\n\n**Batch 3** (parallel, after Batch 2 completes):\n\n| Specialist | Agent File | Claude model | Output |\n|-----------|-----------|-------|--------|\n| Infrastructure | `agents\u002Fcto-infrastructure.md` | sonnet | `.pipeline\u002Fassessment\u002Fcto-infrastructure.md` |\n| Observability | `agents\u002Fcto-observability.md` | sonnet | `.pipeline\u002Fassessment\u002Fcto-observability.md` |\n| Developer Experience | `agents\u002Fcto-devex.md` | sonnet | `.pipeline\u002Fassessment\u002Fcto-devex.md` |\n\n**Subagent prompt template:**\n\n```\nYou are the [Specialist Name]. Read your persona from agents\u002F[agent-file].\n\nAssess the codebase in [project directory]. Here is the file listing:\n[file listing]\n\n[Tech-context if available]\n\nWrite your findings to .pipeline\u002Fassessment\u002F[agent-name].md following the output format\ndefined in your persona file. Be thorough — this is a deep assessment, not a surface scan.\n```\n\n**For `--area` mode:** Dispatch only the named specialist. Skip Steps 5-6 (no CTO synthesis\nfor single-area assessments). Present the specialist report directly.\n\n### 4b. Structure Verification\n\nAfter specialist reports complete, verify that the actual codebase structure matches\ndocumented architectural decisions. This catches assumption drift — where code evolves\naway from what was decided, or decisions were never documented.\n\n**Checks:**\n1. **ADR compliance** — For each ADR in `.docs\u002Fdecisions\u002F`, verify the decision is reflected\n   in code. Flag violations where code contradicts a documented decision.\n2. **Undocumented decisions** — Flag architectural patterns in code that have no corresponding\n   ADR (e.g., a new external integration, a new persistence strategy, a service decomposition\n   that was never decided on paper).\n3. **Stale ADRs** — Flag ADRs whose referenced code no longer exists or has been substantially\n   rewritten without updating the decision record.\n\nThis feeds into the CTO orchestrator synthesis as a \"structure verification\" section.\n\n### 5. Dispatch CTO Orchestrator\n\n**Rate limit cooldown: sleep 30 seconds before dispatching the CTO orchestrator.**\n\nAfter all 9 specialist reports are written, dispatch the CTO orchestrator:\n\n```\nYou are the CTO Orchestrator. Read your persona from agents\u002Fcto-orchestrator.md.\n\nHere are the 9 specialist reports:\n[inline all 9 reports from .pipeline\u002Fassessment\u002F]\n\nUse the template at [absolute path of this skill's templates\u002Ftechnical-assessment.md.template].\nProject name: [project name]\nDate: [YYYY-MM-DD]\n\nWrite the final assessment report to .docs\u002Fdecisions\u002Ftechnical-assessment-[YYYY-MM-DD].md.\n```\n\n**Claude model:** opus (cross-referencing 9 reports requires deep reasoning).\n\n### 6. Present Findings\n\nAfter the CTO orchestrator writes the final report:\n\n1. Present the report to the user via `review_artifacts`\n2. Highlight the **verdict** (HEALTHY \u002F NEEDS_WORK \u002F CRITICAL)\n3. Highlight **critical findings** count and **quick wins** count\n4. If CRITICAL: recommend running `\u002Fassess --area \u003Cname>` for deeper dives on problem areas\n\n### 7. Record Assessment\n\nSave assessment metadata to `.pipeline\u002Fconduct-state.json`:\n```json\n{\n  \"assess\": \"done\",\n  \"assess_date\": \"YYYY-MM-DD\",\n  \"assess_verdict\": \"HEALTHY|NEEDS_WORK|CRITICAL\"\n}\n```\n\n## Verdict Definitions\n\n| Verdict | Criteria | Implication |\n|---------|----------|-------------|\n| **HEALTHY** | No critical findings. Systemic patterns are minor. | Proceed to feature work. |\n| **NEEDS_WORK** | No critical findings, but systemic patterns need addressing. | Feature work can proceed with caution. Assessment feeds `\u002Fexplore`. |\n| **CRITICAL** | Critical findings exist OR 3+ systemic patterns at important+ severity. | Address findings before feature work. Assessment findings become the backlog. |\n\n## Verification\n\n- [ ] `.pipeline\u002Fassessment\u002F` directory created\n- [ ] All 9 specialist reports written (or single report for `--area` mode)\n- [ ] CTO orchestrator report written to `.docs\u002Fdecisions\u002Ftechnical-assessment-YYYY-MM-DD.md`\n- [ ] Report follows template structure from `templates\u002Ftechnical-assessment.md.template` (relative to\n  this skill's own directory)\n- [ ] Verdict is one of: HEALTHY, NEEDS_WORK, CRITICAL\n- [ ] Assessment metadata saved to `.pipeline\u002Fconduct-state.json`\n- [ ] Report presented to user for review\n","## Purpose\n\nPerforms a comprehensive technical assessment of a codebase using 9 specialist agents that each\ndeeply evaluate one dimension of code health, followed by a CTO orchestrator that synthesizes\nfindings into a prioritized report with opinionated recommendations.\n\n**Correctness gate:** every finding is a claim about the codebase. Per the `\u002Fverify-claims`\nprotocol, each specialist finding carries a grounded confidence % and its basis (`verified` — you\nobserved it in the code — vs `inferred`), never asserts a finding it has not verified, and marks a\nlow-confidence judgment as **tentative** rather than stating it as fact. The CTO orchestrator must\nnot raise a finding's confidence beyond what its evidence supports when prioritizing.\n\n### Provider-native delegation\n\nDispatch each specialist through the selected host's available subagent facility. Preserve the\nspecialist persona, fresh assessment context, report output, and the assessment gates regardless\nof host. **Claude delegation:** Claude uses the Agent tool; the Claude model names below apply\nonly to that facility. A Codex-selected run uses its available subagent facility and configured\nCodex provider policy, without translating Claude model names.\n\n**Invocation:**\n- **Onboarding:** Runs as part of `\u002Fconduct` after bootstrap for existing projects\n- **On-demand:** User invokes `\u002Fassess` anytime for a health check\n- **Selective:** `\u002Fassess --area security` runs only the security specialist\n\n## Practices\n\n### 1. Determine Scope\n\nCheck invocation arguments:\n\n| Argument | Behavior |\n|----------|----------|\n| _(none)_ | Full assessment — all 9 specialists + CTO synthesis |\n| `--area \u003Cname>` | Single specialist only (security, data-integrity, dependencies, architecture, duplication, testing, infrastructure, observability, devex) |\n\n### 2. Prepare Assessment Directory\n\nCreate `.pipeline\u002Fassessment\u002F` if it doesn't exist. Clear any stale reports from previous runs.\n\n### 3. Gather Shared Context\n\nBefore dispatching specialists, gather context they all need:\n\n1. **Codebase file listing** — `find . -type f` filtered to source\u002Fconfig files (exclude vendor, node_modules, .git, tmp, log)\n2. **Tech-context** — if loaded in session from `\u002Fbootstrap`, include it\n3. **Existing decisions** — list files in `.docs\u002Fdecisions\u002F` so architecture specialist can cross-reference\n\n### 4. Dispatch Specialists (3 Batches of 3)\n\nDispatch specialists in parallel within each batch, sequential between batches.\nEach specialist is a subagent using the corresponding agent persona.\n\n**Batch 1** (parallel):\n\n| Specialist | Agent File | Claude model | Output |\n|-----------|-----------|-------|--------|\n| Security Auditor | `agents\u002Fcto-security.md` | opus | `.pipeline\u002Fassessment\u002Fcto-security.md` |\n| Data Integrity Reviewer | `agents\u002Fcto-data-integrity.md` | opus | `.pipeline\u002Fassessment\u002Fcto-data-integrity.md` |\n| Dependency Auditor | `agents\u002Fcto-dependencies.md` | sonnet | `.pipeline\u002Fassessment\u002Fcto-dependencies.md` |\n\n**Rate limit cooldown: sleep 30 seconds before dispatching Batch 2.**\n\n**Batch 2** (parallel, after Batch 1 completes):\n\n| Specialist | Agent File | Claude model | Output |\n|-----------|-----------|-------|--------|\n| Architecture Coherence | `agents\u002Fcto-architecture.md` | opus | `.pipeline\u002Fassessment\u002Fcto-architecture.md` |\n| Code Duplication | `agents\u002Fcto-duplication.md` | sonnet | `.pipeline\u002Fassessment\u002Fcto-duplication.md` |\n| Test Strategy | `agents\u002Fcto-testing.md` | sonnet | `.pipeline\u002Fassessment\u002Fcto-testing.md` |\n\n**Rate limit cooldown: sleep 30 seconds before dispatching Batch 3.**\n\n**Batch 3** (parallel, after Batch 2 completes):\n\n| Specialist | Agent File | Claude model | Output |\n|-----------|-----------|-------|--------|\n| Infrastructure | `agents\u002Fcto-infrastructure.md` | sonnet | `.pipeline\u002Fassessment\u002Fcto-infrastructure.md` |\n| Observability | `agents\u002Fcto-observability.md` | sonnet | `.pipeline\u002Fassessment\u002Fcto-observability.md` |\n| Developer Experience | `agents\u002Fcto-devex.md` | sonnet | `.pipeline\u002Fassessment\u002Fcto-devex.md` |\n\n**Subagent prompt template:**\n\n```\nYou are the [Specialist Name]. Read your persona from agents\u002F[agent-file].\n\nAssess the codebase in [project directory]. Here is the file listing:\n[file listing]\n\n[Tech-context if available]\n\nWrite your findings to .pipeline\u002Fassessment\u002F[agent-name].md following the output format\ndefined in your persona file. Be thorough — this is a deep assessment, not a surface scan.\n```\n\n**For `--area` mode:** Dispatch only the named specialist. Skip Steps 5-6 (no CTO synthesis\nfor single-area assessments). Present the specialist report directly.\n\n### 4b. Structure Verification\n\nAfter specialist reports complete, verify that the actual codebase structure matches\ndocumented architectural decisions. This catches assumption drift — where code evolves\naway from what was decided, or decisions were never documented.\n\n**Checks:**\n1. **ADR compliance** — For each ADR in `.docs\u002Fdecisions\u002F`, verify the decision is reflected\n   in code. Flag violations where code contradicts a documented decision.\n2. **Undocumented decisions** — Flag architectural patterns in code that have no corresponding\n   ADR (e.g., a new external integration, a new persistence strategy, a service decomposition\n   that was never decided on paper).\n3. **Stale ADRs** — Flag ADRs whose referenced code no longer exists or has been substantially\n   rewritten without updating the decision record.\n\nThis feeds into the CTO orchestrator synthesis as a \"structure verification\" section.\n\n### 5. Dispatch CTO Orchestrator\n\n**Rate limit cooldown: sleep 30 seconds before dispatching the CTO orchestrator.**\n\nAfter all 9 specialist reports are written, dispatch the CTO orchestrator:\n\n```\nYou are the CTO Orchestrator. Read your persona from agents\u002Fcto-orchestrator.md.\n\nHere are the 9 specialist reports:\n[inline all 9 reports from .pipeline\u002Fassessment\u002F]\n\nUse the template at [absolute path of this skill's templates\u002Ftechnical-assessment.md.template].\nProject name: [project name]\nDate: [YYYY-MM-DD]\n\nWrite the final assessment report to .docs\u002Fdecisions\u002Ftechnical-assessment-[YYYY-MM-DD].md.\n```\n\n**Claude model:** opus (cross-referencing 9 reports requires deep reasoning).\n\n### 6. Present Findings\n\nAfter the CTO orchestrator writes the final report:\n\n1. Present the report to the user via `review_artifacts`\n2. Highlight the **verdict** (HEALTHY \u002F NEEDS_WORK \u002F CRITICAL)\n3. Highlight **critical findings** count and **quick wins** count\n4. If CRITICAL: recommend running `\u002Fassess --area \u003Cname>` for deeper dives on problem areas\n\n### 7. Record Assessment\n\nSave assessment metadata to `.pipeline\u002Fconduct-state.json`:\n```json\n{\n  \"assess\": \"done\",\n  \"assess_date\": \"YYYY-MM-DD\",\n  \"assess_verdict\": \"HEALTHY|NEEDS_WORK|CRITICAL\"\n}\n```\n\n## Verdict Definitions\n\n| Verdict | Criteria | Implication |\n|---------|----------|-------------|\n| **HEALTHY** | No critical findings. Systemic patterns are minor. | Proceed to feature work. |\n| **NEEDS_WORK** | No critical findings, but systemic patterns need addressing. | Feature work can proceed with caution. Assessment feeds `\u002Fexplore`. |\n| **CRITICAL** | Critical findings exist OR 3+ systemic patterns at important+ severity. | Address findings before feature work. Assessment findings become the backlog. |\n\n## Verification\n\n- [ ] `.pipeline\u002Fassessment\u002F` directory created\n- [ ] All 9 specialist reports written (or single report for `--area` mode)\n- [ ] CTO orchestrator report written to `.docs\u002Fdecisions\u002Ftechnical-assessment-YYYY-MM-DD.md`\n- [ ] Report follows template structure from `templates\u002Ftechnical-assessment.md.template` (relative to\n  this skill's own directory)\n- [ ] Verdict is one of: HEALTHY, NEEDS_WORK, CRITICAL\n- [ ] Assessment metadata saved to `.pipeline\u002Fconduct-state.json`\n- [ ] Report presented to user for review\n",{"name":5,"model":44,"phase":45,"requires":46,"standalone":48,"description":7,"enforcement":19,"disable-model-invocation":48},"sonnet","understand",[47],"verify-claims",true,"main","136b34ec6792f53d0beba330dfa2dffad6c93484","skills\u002Fassess",2,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor","https:\u002F\u002Fgithub.com\u002Fjstoup111","2026-11-14 14:59:43",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":48},[58,61,64],{"tool":59,"command":60},"npx","npx skills add jstoup111\u002Fai-conductor --skill assess",{"tool":62,"command":63},"bunx","bunx skills add jstoup111\u002Fai-conductor --skill assess",{"tool":65,"command":66},"pnpm","pnpm dlx skills add jstoup111\u002Fai-conductor --skill assess","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fassess\u002FSKILL.md",[69,75],{"path":70,"resourceType":71,"resourceTypeDesc":72,"sizeBytes":73,"sourceHtmlUrl":74},"agents\u002Fopenai.yaml","REFERENCE","参考文档",43,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fassess\u002Fagents\u002Fopenai.yaml",{"path":76,"resourceType":77,"resourceTypeDesc":78,"sizeBytes":79,"sourceHtmlUrl":80},"templates\u002Ftechnical-assessment.md.template","OTHER","其他",51,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fassess\u002Ftemplates\u002Ftechnical-assessment.md.template",[82,100,138,161,180,196],{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":39},"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",[],[89,90,91,92,93,94,95,96,30,97,26,98,99],"build","dependency hygiene","dependency","hygiene","build review dependency hygiene","review","feature","diff","license","judge","gating",{"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":119,"publishedAt":39},"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",[106,111,114],{"categoryNo":107,"categoryName":108,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":112,"categoryName":113,"taxonomyType":109,"taxonomyTypeDesc":110},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":115,"categoryName":116,"taxonomyType":117,"taxonomyTypeDesc":118},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[120,121,122,123,124,125,126,127,128,129,130,131,24,132,133,134,135,99,136,137],"writing","system","tests","writing system tests","projects","headless","project","end","implementing","frontend","acceptance","api","directory","ui","framework","failing","phase","request",{"skillNo":139,"name":47,"nameZh":6,"description":140,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":141,"categories":142,"keywords":143,"publishedAt":39},"01M6K3EHR0QQ1QY1S9RC6D1WTD","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",[],[144,24,35,145,146,23,147,148,26,149,150,32,151,152,153,154,155,156,157,158,159,99,160],"verify claims","do","adr","decision","claim","mechanics","only","workflow","code","reports","plan","active","questions","about","spec","invoke","when",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":167,"publishedAt":39},"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",[],[163,168,169,170,128,171,94,172,173,174,175,95,176,26,32,177,178,179,160,136],"green","cycle","structural","commit","at","bugfix","integrity","domain","development","with","test","test-first",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":186,"publishedAt":39},"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",[],[182,187,145,23,188,189,190,26,150,32,130,191,38,192,24,193,35,194,155,195,159,99,160],"conduct","decide","engineer","general","requirements","examples","artifact","requests","implementation",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":202,"publishedAt":39},"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",[],[203,204,205,177,24,206,207,208,35,95,209,210,211,212,213,26,214,150,32,215,160,19],"stack","land","stack land","evidence","child","changes","inspect","manual","correct","landing","safe","operator","confirmation"]