[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6K3ED4NF5DJA2Y35MH2JCRC":3,"skill-same:01M6K3ED4NF5DJA2Y35MH2JCRC":88},{"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":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":46,"commitSha":47,"skillDirectory":48,"forksCount":49,"repositoryHtmlUrl":50,"repositoryHomepageUrl":6,"ownerHtmlUrl":51,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":52,"install":53,"resources":65},"01M6K3ED4NF5DJA2Y35MH2JCRC","tdd",null,"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.","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\u002Ftdd\u002FSKILL.md",[],[5,19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"domain","phase","when","test-first","test","with","use","true","development","feature","integrity","bugfix","at","review","commit","implementing","structural","cycle","green","2026-11-10 10:12:30",false,"---\nname: tdd\ndisable-model-invocation: true\ndescription: \"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.\"\nenforcement: structural\nphase: build\nstandalone: true\nrequires: []\n---\n\n## Purpose\n\nEnforces test-driven development with domain integrity as a first-class concern. Every change\ngoes through a five-step cycle with implementer isolation — the RED agent only sees tests, the\nGREEN agent only sees source, and the DOMAIN reviewer has veto authority over both.\n\n**Host mechanics:** Delegate RED, GREEN, and DOMAIN work through the selected host's available\nsubagent facility. Claude Code uses its Agent tool and Claude model labels; other supported hosts\nuse their native equivalents. The host mechanism may differ, but it MUST preserve this cycle's\nRED → DOMAIN → GREEN → DOMAIN → COMMIT order, scoped verification, review vetoes, and commit gates.\n\n### Documentation boundary\n\nDo not start a RED\u002FGREEN cycle for ordinary human-facing documentation, and do not add tests that\nassert documentation wording, headings, formatting, placement, links, or repository explanations.\nDocumentation-only requests are delivered from `\u002Fexplore`. Keep tests for machine-consumed documents\nonly when they assert generated or runtime behavior (for example OpenAPI contracts or generated\nrepository-harness functionality), never prose shape.\n\n### Suite-failure repair\n\nWhen BUILD returns after `test_suite` fails, read the engine's retry diagnostics and\nreferenced `.pipeline\u002Ftest-suite-evidence.json`, and include the relevant failure evidence\nin RED\u002FGREEN dispatches. Repair and verify the affected tests through\n`ai-conductor scoped-run \u003Cselectors...>`, then commit. Leave aggregate re-verification to\n`test_suite`; a scoped PASS does not establish an aggregate PASS.\n\n### SHIP verdict artifacts are read-only\n\nDuring BUILD, `.pipeline\u002Fprd-audit.json` is the typed PRD verdict authority (ADR D2.2), and\n`.pipeline\u002Fprd-audit.md` is its derived human report. `.pipeline\u002Farchitecture-review-as-built.md`,\n`.pipeline\u002Farchitecture-review-as-built.json`, `.pipeline\u002Fprd-audit-code-stamp.json`, and\n`.pipeline\u002Farchitecture-review-as-built-code-stamp.json` are read-only SHIP validator evidence.\nNever write, delete, rename, or recreate them. Reading `.pipeline\u002Fremediation.json` and the cited\nverdict artifact remains allowed. Use that read-only evidence when the task needs finding detail.\n\n## Practices\n\n### The Cycle\n\n```\nRED → DOMAIN → GREEN → DOMAIN → COMMIT\n │       │        │        │        │\n │       │        │        │        └─ Scoped affected-test union green, clean tree, commit\n │       │        │        └─ Review implementation for domain integrity\n │       │        └─ Implement the smallest behavior-complete change within scope\n │       └─ Review test for primitive obsession, invalid states\n └─ Write ONE failing test, watch it fail\n```\n\n### Declared Replication Does Not Change the Cycle\n\nA declared replication's copy task establishes a baseline; it never shortens or changes the\ncycle for a later delta task. A task that introduces behavior the source lacks runs the full RED → DOMAIN → GREEN → DOMAIN → COMMIT cycle, with the same scoped verification and review gates,\nwhether the plan declares replication or not.\n\n`Evidence: satisfied-by \u003Ccopy-sha>` may close a later task only when the copied commit satisfies\nthat task's **whole** scope: every acceptance criterion and its required scoped verification. A\ncopy commit cannot close a task merely because it supplies some of the behavior, and cannot close\na task that introduces behavior absent from the source. Do not split a partly covered task into a\ncopy-satisfied portion and a delta portion. If whole-task satisfaction is ambiguous, resolve the\nambiguity toward the full cycle.\n\nFor a delta task, a first test that passes immediately does not permit implementation. Investigate\nwhether the test only restates copied behavior or is otherwise wrong;\nthen write a failing test for the task's uncovered behavior. Only a separate proof that the copy\nsatisfies the whole task may use the existing `Evidence: satisfied-by` closure.\n\n### No Legitimate RED for Already-Existing Behavior\n\nPlan-declared Verify-only refactor and dependency-upgrade maintenance tasks follow this section;\ndeletion tasks follow **Removal Boundary**. A maintenance task that changes observable behavior\nfollows the full RED → GREEN cycle.\n\nThis boundary applies only when there is no behavior left to add, change, or fix. It never applies\nto a task that adds, changes, or fixes behavior; those tasks run the full RED → DOMAIN → GREEN →\nDOMAIN → COMMIT cycle.\n\nFor a plan-declared verify-only\u002Fverification task, author at most the documenting test explicitly\nasked for by the plan. Do not invent unrelated assertions to manufacture a RED result.\n\nIf investigation discovers that the behavior already exists but the sealed plan did not declare the\ntask verify-only\u002Fverification, do not author a test that cannot fail. Delete any redundant test\nauthored during this lap, do not amend the sealed plan, and close the task with the existing\n`Evidence: skipped \u003Creason>` empty-commit form in **Commit-less Completions: Evidence Trailers**.\n\n### Removal Boundary\n\nDeleting code starts no RED cycle. For removal-shaped work, follow `\u002Fcode-removal` for the\nabsence-test prohibition, survivor method, test triage, and completeness sweep. Maintenance edits\nthat keep existing tests compiling after a removal (updating imports, dropping dead selectors) are\nordinary edits and need no RED of their own.\n\n### Phase 1: RED\n\n**Agent:** Generator (test-files-only context).\n**Goal:** Write exactly one failing test that captures the next behavior.\n\n1. Choose the next acceptance criterion from the plan (or the most obvious next behavior)\n2. Write one test for one behavior\n3. The agent derives selectors, retains the test under change as an expected failing member,\n   and runs the scoped union of affected tests through `ai-conductor scoped-run \u003Cselectors...>`\n4. Confirm that the test under change fails for the expected reason and every\n   other affected test passes\n5. Paste the expected failure output\n\nAny unrelated scoped test failure blocks the current RED phase; fix that\nfailure in a separate commit (`Scope:` trailer for any file outside the task's\nFiles) before proceeding to DOMAIN. If one of the repository's documented\nintermediate fallback triggers makes the affected set genuinely unsafe, name\nthe exact trigger and reason and defer aggregate proof to the engine's\ndedicated aggregate gate. Never run the full suite — or any aggregate\ncommand — inside this session.\n\n**Rules:**\n- One test, one behavior; assert every outcome its `Covers:` target names (content, not only a count or call)\n- Test must fail for the RIGHT reason (not a syntax error; a missing import of not-yet-written code\n  is expected, but COMMIT step 5's stub check still applies)\n- Assert production behavior, not source text, a test-local helper or fixture, or a mock's canned return\n- Together, the tests for each `Covers:` target must fail against a stub of the code under test\n  (constant, empty, or pre-change return); a negative-path test may pass a stub only if you can\n  name the sibling test in this change that fails it\n- Test name describes the behavior: `test_expired_token_returns_401`, not `test_auth`\n- If tech-context loaded: follow stack test conventions (e.g., RSpec `describe`\u002F`context`\u002F`it`)\n- **Declare feature coverage with a `Covers:` marker.** Every test file this cycle creates or\n  changes carries a `Covers:` comment binding it to the active feature, using the same marker\n  contract as `\u002Fwriting-system-tests`: a criterion in the active stories (`Covers: S\u003Cn>.\u003Cm>`), a\n  task in the active plan (`Covers: task:\u003Cid>`), or — product track — a PRD requirement\n  (`Covers: FR-N`). Criterion ids are positional — `S\u003Cn>.\u003Cm>` names the m-th Given\u002FWhen\u002FThen bullet\n  of Story n, happy-path bullets before negative-path ones; story files carry no literal ids.\n  Add or update the marker in the current feature diff; an unchanged marker inherited from the\n  review base belongs to its earlier feature and is not current-feature authority, even when its\n  bare ordinal happens to resolve in the active plan. Markers are resolvable only against the feature's own stories and plan; the\n  build_review test-quality rubric scopes itself to changed tests with a resolvable `Covers:`\n  binding, so a changed test without one is invisible to that review and the rubric passes\n  vacuously. Put the marker directly above the `it`\u002F`describe` it covers; a file-header marker binds\n  every test in the file, so use one only in files without test declarations.\n\n**If the test passes immediately:** The behavior already exists. Either the test is wrong\n(testing something already implemented) or the criterion is already met. Investigate — don't\nmove to GREEN.\n\nSee `references\u002Fred.md` for detailed RED phase guidance.\n\n### Phase 2: DOMAIN (Post-RED)\n\n**Agent:** Domain Reviewer (see `agents\u002Fdomain-reviewer.md` for full criteria)\n**Goal:** Review the test for domain integrity — primitive obsession, invalid states, boundary\nviolations, domain language, and **adversarial-derivation coverage** (a failing spec per\nproduction call site of any security\u002Fcorrectness derivation, with real adversarial input — see\n`\u002Fwriting-system-tests` §3d). Has veto authority to send back to RED.\n\n> When the task touches a security\u002Fcorrectness derivation (redaction, auth\u002Fpermission predicate,\n> path\u002Fidentity check, state guard), the dispatcher MUST include the derivation's production\n> call-site list (`file:line`) in this reviewer's prompt — the reviewer is told not to scan, so\n> without the list it cannot check call-site coverage.\n\n### Phase 3: GREEN\n\n**Agent:** Generator (source-files-only context).\n**Goal:** Write the smallest behavior-complete code change that makes the failing test pass and\nconforms to the applicable recorded basis.\n\n1. **Scope check BEFORE writing code:**\n   - Will this change touch ~20 lines or fewer? → Proceed\n   - Will it touch more than 1 file? → Consider drill-down\n   - Will it touch more than 1 function? → Consider drill-down\n   - If scope check fails → Write a unit test for the smaller piece and run a nested TDD cycle\n\n2. When an applicable recorded basis is present, conform to its relevant semantic traits. A\n   verified no-fit or operator-authorized bounded departure follows its documented approach;\n   when no applicable basis exists, no pattern conformance is required.\n3. Write the smallest behavior-complete code change to pass the test\n4. Run the test — **watch it pass**\n5. The agent derives the selectors for the affected\u002Fscoped test set (the task's own tests + the files this change touches) and runs `ai-conductor scoped-run \u003Cselectors...>`. The dedicated pre-SHIP gate and CI own broad verification, not each TDD cycle.\n\nA known failure in that scoped set blocks the current GREEN phase; fix it here,\nin a separate commit (`Scope:` trailer for any file outside the task's Files),\nrather than deferring it to a later gate. If one of the repository's documented\nintermediate fallback triggers makes the affected set genuinely unsafe, name\nthe exact trigger and defer aggregate proof to the engine's dedicated\naggregate gate. Never run the full suite — or any aggregate command —\ninside this session.\n\n**Rules:**\n- The smallest behavior-complete change must conform to an applicable recorded basis; a passing\n  change that materially departs from that basis without its recorded no-fit or authorized\n  departure is incomplete. This does not authorize behavior beyond the failing test.\n- Don't implement behavior not required by a failing test.\n- Don't fix other things you notice. Note them for a future task. A `Scope:` trailer explains a\n  widening; it does not authorize a user-visible behavior change.\n- Do not refactor during GREEN; refactoring remains a separate batch-boundary activity.\n- If tech-context loaded: follow stack conventions (e.g., Rails model\u002Fcontroller patterns)\n\n**When GREEN won't go green — escalate to debugging, do not thrash.**\nIf the target test still fails after a bounded attempt (≈2 edits), or step 4 shows the change\nbroke other tests and the cause is not immediately obvious, STOP editing. A generator guessing\nat a non-obvious failure burns tokens and risks masking the bug rather than fixing it. Dispatch\nthe `\u002Fdebugging` protocol in a fresh sub-session. In Claude Code, use **`model=\"opus\"** for this\nreasoning-heavy root-cause analysis (see the repository's model table); other supported hosts use\ntheir native high-reasoning equivalent. Hand it the failing test, the current\ndiff, and the full failure output. Return to GREEN only once debugging has produced an\nevidence-backed root cause.\n\nSee `references\u002Fgreen.md` for detailed GREEN phase guidance.\nSee `references\u002Fdrill-down.md` for nested TDD cycle instructions.\n\n### Phase 4: DOMAIN (Post-GREEN)\n\n**Mechanical pre-check (before dispatching the reviewer):** If tech-context defines a type-check\ncommand for a statically-typed stack (e.g. `tsc --noEmit` \u002F `npm run typecheck` for TypeScript),\nrun it now. A type error returns straight to GREEN — do NOT dispatch the domain reviewer (or\nadvance to COMMIT) against code that does not type-check. Skip silently for stacks with no compile\nstep (e.g. Rails — the linter at COMMIT covers static checks there).\n\n**Agent:** Domain Reviewer (see `agents\u002Fdomain-reviewer.md` for full criteria)\n**Goal:** Review the implementation for domain integrity — primitive obsession, leaky\nabstractions, missing domain types, naming, and **derivation-reached-at-every-call-site** (every\ncall site actually routes through the security\u002Fcorrectness derivation, handling real boundary\ninputs without failing open or closed). Has veto authority to send back to GREEN.\n\n### Phase 5: COMMIT\n\n**Hard gate — all conditions must be met:**\n\n1. Scoped affected-test set passes (the engine's dedicated aggregate gate and CI own broad verification, not each task)\n2. Linter passes (if tech-context specifies one — e.g., `bundle exec standardrb` for Rails)\n3. Type-check passes (if tech-context specifies a type-checker — e.g., `tsc --noEmit` \u002F\n   `npm run typecheck` for TypeScript). Already run as the Phase 4 pre-check; re-confirm clean here.\n4. Working tree is clean (no uncommitted changes outside this task)\n5. **Pre-diff sensitivity check** — for every NEW or CHANGED test in this task that claims to\n   cover new or changed behavior: create a temporary detached worktree at the base commit (`git worktree add --detach «tmp» «base»`), copy only the new or changed test files into it, run them there, then remove that temporary worktree with `git worktree remove --force «tmp»`.\n   Change no worktree's files beyond adding those copies, the temporary one included: never set\n   uncommitted work aside, and never discard, roll back or overwrite paths to reach the base\n   version. A test that still passes proves nothing\n   and will fail build_review's testQuality rubric one expensive lap later. A test that fails there\n   only because the new module is missing proves nothing either; apply the stub rule from RED. A value computed by the\n   test but never asserted on is an automatic fail of this check. Exempt: tasks under the\n   **No Legitimate RED for Already-Existing Behavior** and **Removal Boundary** sections, and\n   plan-declared `**Verify-only:** yes` tasks — their evidence forms replace this check.\n6. **Commit immediately** — do not defer commits to end of cycle or batch. Connection\n   interruptions lose uncommitted work. Commit as soon as GREEN passes and linter is clean.\n7. Commit with descriptive message referencing the behavior added\n8. **Commit includes Task trailer** — every commit in this cycle (feature, refactor, fixup)\n   carries `Task: \u003Cid>` with the bare plan header id (`### Task 7:` → `Task: 7`, never\n   `Task: task-7`). The commit-msg hook stamps it from `.pipeline\u002Fcurrent-task`; confirm it parsed.\n\n9. **Cross-boundary integration proved by its owning task.** When the current task owns a\n   cross-boundary integration check under `\u002Fplan` §3d, a test (new or existing) must exercise the\n   changed behavior through the appropriate project entry point named by that check—for example a\n   public API or route, CLI, job or worker, event consumer, framework hook, or application-service\n   boundary. A direct helper test alone cannot close that task. Tasks that do not own a changed\n   boundary remain at the lowest sufficient test layer; production-file count does not create\n   integration-test obligations.\n\n10. **Commit only to the current feature branch — never integrate upstream.** Do NOT run\n   `git fetch`, `git pull`, `git rebase`, or switch branches during the cycle. Mid-build\n   rebase onto a moved `origin\u002F\u003Cdefault>` rewrites history under active work. The only\n   sanctioned rebases run outside this loop.\n\n**After commit:** Return to RED for the next cycle. Stop only when every `Done when:` bullet,\nincluding each enumerated case and negative outcome, has a committed assertion you can cite.\n\n### Commit-less Completions: Evidence Trailers\n\nNot all tasks require code commits. Some tasks verify that existing behavior meets acceptance\ncriteria, and some have no implementation work (architectural decisions, etc.). Ordinary\ndocumentation maintenance is not a TDD task; `\u002Fexplore` delivers it directly.\nWhen a task completes without code changes, emit an empty commit with Evidence trailers.\n\nA plan task may carry a `**Verify-only:** yes` marker (see `skills\u002Fplan\u002FSKILL.md` §5d)\ndeclaring up front that it is expected to prove existing behavior already satisfies its\nacceptance criteria. Such tasks preferably complete via one of the two empty-commit\nEvidence forms below — `Evidence: satisfied-by \u003Csha>` when a prior commit already\nsatisfies the criteria, or `Evidence: skipped \u003Creason>` when there is no applicable\nsatisfying commit — rather than a code commit.\n\nEvidence forms MUST be emitted as `git commit --allow-empty` with the Evidence trailer in the\ncommit body; the engine reads commits only, not task reports.\n\n**Form 1: `Evidence: satisfied-by \u003Csha>`**\nUse when a task's acceptance criteria are already met by existing code (discovered during\npre-completion scan). Emit a no-op commit carrying the satisfying commit SHA:\n```\ngit commit --allow-empty -m \"chore(evidence): task criteria met\" \\\n  -m \"Task: 7\" \\\n  -m \"Evidence: satisfied-by abc123def456\"\n```\n\n**Form 2: `Evidence: skipped \u003Creason>`**\nUse when a task has no implementation work or is intentionally deferred. Emit a no-op commit\nwith a concise reason:\n```\ngit commit --allow-empty -m \"chore(evidence): task deferred\" \\\n  -m \"Task: 12\" \\\n  -m \"Evidence: skipped awaiting_stakeholder_input\"\n```\n\nEach empty commit carries `Task: \u003Cid>` plus one Evidence form; the conductor records the task as\ncompleted by verification rather than code delivery.\n\n### Memory Checkpoint (Per-Cycle, Conditional)\n\nAfter COMMIT, if this TDD cycle revealed any of the following, persist immediately:\n- **Category: `gotchas\u002F`** — An unexpected framework\u002Flibrary behavior that caused the test to fail for the wrong reason\n- **Category: `patterns\u002F`** — A new pattern established in this cycle that future cycles should follow\n\nMost cycles will NOT trigger a memory write — that is correct. Only persist genuinely surprising discoveries.\n\n### Refactoring\n\nRefactoring never happens during GREEN. It runs at batch boundaries through the `simplify` workflow\n(Claude `\u002Fsimplify`; Codex `$simplify`), in its own commits, and uses simplify's thresholds.\n\n### User-Requested Exit During TDD\n\nIf the user explicitly requests to stop, pause, or exit to the harness at any point during\na TDD cycle (RED, GREEN, DOMAIN, or COMMIT), the orchestrator MUST:\n\n1. **Do NOT commit incomplete work.** If the cycle is mid-flight (test written but no code,\n   or code written but domain review not passed), do not attempt to force a commit.\n\n2. **Write a halt marker** (`.pipeline\u002Fhalt-user-input-required`) with a one-line summary\n   of the in-flight cycle state (e.g., \"user requested exit; RED phase complete, awaiting GREEN\").\n\n### Structural Enforcement\n\nWhen dispatching through the selected host's available subagent facility, give each phase only\nthe context below — paths and metadata, not file contents. In Claude Code, this applies to Agent\ntool dispatches.\n\n| Phase | Agent | Provide in Prompt | Do NOT Provide |\n|-------|-------|-------------------|----------------|\n| RED | Generator | Task description, acceptance criterion text, test dir path, factory file path | Implementation files, other stories, full plan |\n| DOMAIN (post-RED) | Domain Reviewer | New\u002Fchanged test code (inline), list of existing domain types, **call-site list (`file:line`) for any security\u002Fcorrectness derivation in scope** | Full file tree, `.memory\u002F` files, other test files |\n| GREEN | Generator | Failing test output (inline), source dir path, 1-2 specific source files to modify | Test files, stories, plan |\n| DOMAIN (post-GREEN) | Domain Reviewer | New\u002Fchanged implementation code (inline), the test it satisfies (inline), **call-site list (`file:line`) for any security\u002Fcorrectness derivation in scope** | Full file tree, `.memory\u002F` files, other source files |\n| COMMIT | (main agent) | Full context | All files |\n\n**Context budget rules:**\n- **Provide file paths and metadata, not full contents.** Give subagents file paths, line\n  counts, and key method names\u002Fsignatures. Subagents read files themselves.\n- **For domain review: inline the diff only.** Paste the specific new\u002Fchanged code (the diff)\n  into the domain reviewer prompt — this is typically small (\u003C50 lines). Do NOT inline entire files.\n- **Name domain types that exist** (e.g., \"Domain types: Contact, Tag, ContactTag\") so the\n  domain reviewer doesn't scan the codebase.\n- **One criterion per RED dispatch** — the generator prompt contains exactly the acceptance\n  criterion being implemented, not the full story.\n- **Cap GREEN file access** — name the 1-2 files to modify, not the full source tree.\n- **Pre-gather decisions** — the TDD orchestrator checks `.memory\u002Fdecisions\u002F` for relevant\n  prior decisions and includes them in the domain reviewer prompt. The reviewer does not\n  search `.memory\u002F` itself.\n- **Reuse host-native implementer sessions for sequential tasks on same files.** When consecutive\ntasks modify the same files, continue the existing host-native session instead of spawning a new\none — this preserves the file cache and avoids redundant reads.\n\nThis isolation prevents the RED agent from peeking at implementation (biasing the test)\nand the GREEN agent from over-engineering beyond what the test requires.\n\n### Domain Reviewer Model Selection\n\nRight-size the model to the diff size to reduce API cost and rate limit pressure:\n\n- **In Claude Code, diffs under 50 lines:** dispatch with `model=\"sonnet\"` — sufficient for focused domain checks\n- **In Claude Code, diffs of 50+ lines:** dispatch with `model=\"opus\"` — deep analysis for larger changes\n- **Other supported hosts:** select the native equivalent of the same focused versus deep-review\n  capability; do not weaken the review boundary or veto authority.\n\n### Orchestrator Output Discipline\n\nBetween TDD phases, the orchestrator outputs ONLY:\n- The dispatch (silently — no announcement)\n- The subagent's structured response\n- A one-line status: `RED: FAIL (expected)` \u002F `GREEN: PASS` \u002F `DOMAIN: APPROVED` \u002F `DOMAIN: VETO — [reason]`\n\nNo narration, no explanation of what just happened, no preview of what comes next.\n\n### Test Coverage Rule: Behavior and Failure Boundaries\n\nCoverage follows the behavior or failure boundary being added, changed, or fixed — never a\none-to-one correspondence with production files. Choose the lowest sufficient test layer that\nproves the criterion. Use acceptance\u002Fsystem coverage only for a distinct multi-step externally\nobservable flow that cannot be proven sufficiently below it; do not duplicate lower-layer negative\nvariants or existing sufficient proof.\n\nNew behavior and bug fixes still begin with RED. A production-file change alone does not require a\nmirror test, and ordinary natural-language guidance does not create behavior to test. A declared\nexact replication still follows its full delta cycle and required scoped verification.\n\n## Verification\n\n- [ ] Test written BEFORE implementation and failed for the right reason\n- [ ] Domain review ran after RED and after GREEN\n- [ ] Scoped affected-test set, linter, and type-check (typed stacks) pass before commit\n- [ ] Pre-diff sensitivity check run for every new or changed behavioral test\n- [ ] Every new\u002Fchanged test file carries a resolvable `Covers:` marker for the active feature\n- [ ] Any cross-boundary integration check owned by this task is proven through its entry point\n- [ ] Working tree clean at commit; one behavior per cycle\n","## Purpose\n\nEnforces test-driven development with domain integrity as a first-class concern. Every change\ngoes through a five-step cycle with implementer isolation — the RED agent only sees tests, the\nGREEN agent only sees source, and the DOMAIN reviewer has veto authority over both.\n\n**Host mechanics:** Delegate RED, GREEN, and DOMAIN work through the selected host's available\nsubagent facility. Claude Code uses its Agent tool and Claude model labels; other supported hosts\nuse their native equivalents. The host mechanism may differ, but it MUST preserve this cycle's\nRED → DOMAIN → GREEN → DOMAIN → COMMIT order, scoped verification, review vetoes, and commit gates.\n\n### Documentation boundary\n\nDo not start a RED\u002FGREEN cycle for ordinary human-facing documentation, and do not add tests that\nassert documentation wording, headings, formatting, placement, links, or repository explanations.\nDocumentation-only requests are delivered from `\u002Fexplore`. Keep tests for machine-consumed documents\nonly when they assert generated or runtime behavior (for example OpenAPI contracts or generated\nrepository-harness functionality), never prose shape.\n\n### Suite-failure repair\n\nWhen BUILD returns after `test_suite` fails, read the engine's retry diagnostics and\nreferenced `.pipeline\u002Ftest-suite-evidence.json`, and include the relevant failure evidence\nin RED\u002FGREEN dispatches. Repair and verify the affected tests through\n`ai-conductor scoped-run \u003Cselectors...>`, then commit. Leave aggregate re-verification to\n`test_suite`; a scoped PASS does not establish an aggregate PASS.\n\n### SHIP verdict artifacts are read-only\n\nDuring BUILD, `.pipeline\u002Fprd-audit.json` is the typed PRD verdict authority (ADR D2.2), and\n`.pipeline\u002Fprd-audit.md` is its derived human report. `.pipeline\u002Farchitecture-review-as-built.md`,\n`.pipeline\u002Farchitecture-review-as-built.json`, `.pipeline\u002Fprd-audit-code-stamp.json`, and\n`.pipeline\u002Farchitecture-review-as-built-code-stamp.json` are read-only SHIP validator evidence.\nNever write, delete, rename, or recreate them. Reading `.pipeline\u002Fremediation.json` and the cited\nverdict artifact remains allowed. Use that read-only evidence when the task needs finding detail.\n\n## Practices\n\n### The Cycle\n\n```\nRED → DOMAIN → GREEN → DOMAIN → COMMIT\n │       │        │        │        │\n │       │        │        │        └─ Scoped affected-test union green, clean tree, commit\n │       │        │        └─ Review implementation for domain integrity\n │       │        └─ Implement the smallest behavior-complete change within scope\n │       └─ Review test for primitive obsession, invalid states\n └─ Write ONE failing test, watch it fail\n```\n\n### Declared Replication Does Not Change the Cycle\n\nA declared replication's copy task establishes a baseline; it never shortens or changes the\ncycle for a later delta task. A task that introduces behavior the source lacks runs the full RED → DOMAIN → GREEN → DOMAIN → COMMIT cycle, with the same scoped verification and review gates,\nwhether the plan declares replication or not.\n\n`Evidence: satisfied-by \u003Ccopy-sha>` may close a later task only when the copied commit satisfies\nthat task's **whole** scope: every acceptance criterion and its required scoped verification. A\ncopy commit cannot close a task merely because it supplies some of the behavior, and cannot close\na task that introduces behavior absent from the source. Do not split a partly covered task into a\ncopy-satisfied portion and a delta portion. If whole-task satisfaction is ambiguous, resolve the\nambiguity toward the full cycle.\n\nFor a delta task, a first test that passes immediately does not permit implementation. Investigate\nwhether the test only restates copied behavior or is otherwise wrong;\nthen write a failing test for the task's uncovered behavior. Only a separate proof that the copy\nsatisfies the whole task may use the existing `Evidence: satisfied-by` closure.\n\n### No Legitimate RED for Already-Existing Behavior\n\nPlan-declared Verify-only refactor and dependency-upgrade maintenance tasks follow this section;\ndeletion tasks follow **Removal Boundary**. A maintenance task that changes observable behavior\nfollows the full RED → GREEN cycle.\n\nThis boundary applies only when there is no behavior left to add, change, or fix. It never applies\nto a task that adds, changes, or fixes behavior; those tasks run the full RED → DOMAIN → GREEN →\nDOMAIN → COMMIT cycle.\n\nFor a plan-declared verify-only\u002Fverification task, author at most the documenting test explicitly\nasked for by the plan. Do not invent unrelated assertions to manufacture a RED result.\n\nIf investigation discovers that the behavior already exists but the sealed plan did not declare the\ntask verify-only\u002Fverification, do not author a test that cannot fail. Delete any redundant test\nauthored during this lap, do not amend the sealed plan, and close the task with the existing\n`Evidence: skipped \u003Creason>` empty-commit form in **Commit-less Completions: Evidence Trailers**.\n\n### Removal Boundary\n\nDeleting code starts no RED cycle. For removal-shaped work, follow `\u002Fcode-removal` for the\nabsence-test prohibition, survivor method, test triage, and completeness sweep. Maintenance edits\nthat keep existing tests compiling after a removal (updating imports, dropping dead selectors) are\nordinary edits and need no RED of their own.\n\n### Phase 1: RED\n\n**Agent:** Generator (test-files-only context).\n**Goal:** Write exactly one failing test that captures the next behavior.\n\n1. Choose the next acceptance criterion from the plan (or the most obvious next behavior)\n2. Write one test for one behavior\n3. The agent derives selectors, retains the test under change as an expected failing member,\n   and runs the scoped union of affected tests through `ai-conductor scoped-run \u003Cselectors...>`\n4. Confirm that the test under change fails for the expected reason and every\n   other affected test passes\n5. Paste the expected failure output\n\nAny unrelated scoped test failure blocks the current RED phase; fix that\nfailure in a separate commit (`Scope:` trailer for any file outside the task's\nFiles) before proceeding to DOMAIN. If one of the repository's documented\nintermediate fallback triggers makes the affected set genuinely unsafe, name\nthe exact trigger and reason and defer aggregate proof to the engine's\ndedicated aggregate gate. Never run the full suite — or any aggregate\ncommand — inside this session.\n\n**Rules:**\n- One test, one behavior; assert every outcome its `Covers:` target names (content, not only a count or call)\n- Test must fail for the RIGHT reason (not a syntax error; a missing import of not-yet-written code\n  is expected, but COMMIT step 5's stub check still applies)\n- Assert production behavior, not source text, a test-local helper or fixture, or a mock's canned return\n- Together, the tests for each `Covers:` target must fail against a stub of the code under test\n  (constant, empty, or pre-change return); a negative-path test may pass a stub only if you can\n  name the sibling test in this change that fails it\n- Test name describes the behavior: `test_expired_token_returns_401`, not `test_auth`\n- If tech-context loaded: follow stack test conventions (e.g., RSpec `describe`\u002F`context`\u002F`it`)\n- **Declare feature coverage with a `Covers:` marker.** Every test file this cycle creates or\n  changes carries a `Covers:` comment binding it to the active feature, using the same marker\n  contract as `\u002Fwriting-system-tests`: a criterion in the active stories (`Covers: S\u003Cn>.\u003Cm>`), a\n  task in the active plan (`Covers: task:\u003Cid>`), or — product track — a PRD requirement\n  (`Covers: FR-N`). Criterion ids are positional — `S\u003Cn>.\u003Cm>` names the m-th Given\u002FWhen\u002FThen bullet\n  of Story n, happy-path bullets before negative-path ones; story files carry no literal ids.\n  Add or update the marker in the current feature diff; an unchanged marker inherited from the\n  review base belongs to its earlier feature and is not current-feature authority, even when its\n  bare ordinal happens to resolve in the active plan. Markers are resolvable only against the feature's own stories and plan; the\n  build_review test-quality rubric scopes itself to changed tests with a resolvable `Covers:`\n  binding, so a changed test without one is invisible to that review and the rubric passes\n  vacuously. Put the marker directly above the `it`\u002F`describe` it covers; a file-header marker binds\n  every test in the file, so use one only in files without test declarations.\n\n**If the test passes immediately:** The behavior already exists. Either the test is wrong\n(testing something already implemented) or the criterion is already met. Investigate — don't\nmove to GREEN.\n\nSee `references\u002Fred.md` for detailed RED phase guidance.\n\n### Phase 2: DOMAIN (Post-RED)\n\n**Agent:** Domain Reviewer (see `agents\u002Fdomain-reviewer.md` for full criteria)\n**Goal:** Review the test for domain integrity — primitive obsession, invalid states, boundary\nviolations, domain language, and **adversarial-derivation coverage** (a failing spec per\nproduction call site of any security\u002Fcorrectness derivation, with real adversarial input — see\n`\u002Fwriting-system-tests` §3d). Has veto authority to send back to RED.\n\n> When the task touches a security\u002Fcorrectness derivation (redaction, auth\u002Fpermission predicate,\n> path\u002Fidentity check, state guard), the dispatcher MUST include the derivation's production\n> call-site list (`file:line`) in this reviewer's prompt — the reviewer is told not to scan, so\n> without the list it cannot check call-site coverage.\n\n### Phase 3: GREEN\n\n**Agent:** Generator (source-files-only context).\n**Goal:** Write the smallest behavior-complete code change that makes the failing test pass and\nconforms to the applicable recorded basis.\n\n1. **Scope check BEFORE writing code:**\n   - Will this change touch ~20 lines or fewer? → Proceed\n   - Will it touch more than 1 file? → Consider drill-down\n   - Will it touch more than 1 function? → Consider drill-down\n   - If scope check fails → Write a unit test for the smaller piece and run a nested TDD cycle\n\n2. When an applicable recorded basis is present, conform to its relevant semantic traits. A\n   verified no-fit or operator-authorized bounded departure follows its documented approach;\n   when no applicable basis exists, no pattern conformance is required.\n3. Write the smallest behavior-complete code change to pass the test\n4. Run the test — **watch it pass**\n5. The agent derives the selectors for the affected\u002Fscoped test set (the task's own tests + the files this change touches) and runs `ai-conductor scoped-run \u003Cselectors...>`. The dedicated pre-SHIP gate and CI own broad verification, not each TDD cycle.\n\nA known failure in that scoped set blocks the current GREEN phase; fix it here,\nin a separate commit (`Scope:` trailer for any file outside the task's Files),\nrather than deferring it to a later gate. If one of the repository's documented\nintermediate fallback triggers makes the affected set genuinely unsafe, name\nthe exact trigger and defer aggregate proof to the engine's dedicated\naggregate gate. Never run the full suite — or any aggregate command —\ninside this session.\n\n**Rules:**\n- The smallest behavior-complete change must conform to an applicable recorded basis; a passing\n  change that materially departs from that basis without its recorded no-fit or authorized\n  departure is incomplete. This does not authorize behavior beyond the failing test.\n- Don't implement behavior not required by a failing test.\n- Don't fix other things you notice. Note them for a future task. A `Scope:` trailer explains a\n  widening; it does not authorize a user-visible behavior change.\n- Do not refactor during GREEN; refactoring remains a separate batch-boundary activity.\n- If tech-context loaded: follow stack conventions (e.g., Rails model\u002Fcontroller patterns)\n\n**When GREEN won't go green — escalate to debugging, do not thrash.**\nIf the target test still fails after a bounded attempt (≈2 edits), or step 4 shows the change\nbroke other tests and the cause is not immediately obvious, STOP editing. A generator guessing\nat a non-obvious failure burns tokens and risks masking the bug rather than fixing it. Dispatch\nthe `\u002Fdebugging` protocol in a fresh sub-session. In Claude Code, use **`model=\"opus\"** for this\nreasoning-heavy root-cause analysis (see the repository's model table); other supported hosts use\ntheir native high-reasoning equivalent. Hand it the failing test, the current\ndiff, and the full failure output. Return to GREEN only once debugging has produced an\nevidence-backed root cause.\n\nSee `references\u002Fgreen.md` for detailed GREEN phase guidance.\nSee `references\u002Fdrill-down.md` for nested TDD cycle instructions.\n\n### Phase 4: DOMAIN (Post-GREEN)\n\n**Mechanical pre-check (before dispatching the reviewer):** If tech-context defines a type-check\ncommand for a statically-typed stack (e.g. `tsc --noEmit` \u002F `npm run typecheck` for TypeScript),\nrun it now. A type error returns straight to GREEN — do NOT dispatch the domain reviewer (or\nadvance to COMMIT) against code that does not type-check. Skip silently for stacks with no compile\nstep (e.g. Rails — the linter at COMMIT covers static checks there).\n\n**Agent:** Domain Reviewer (see `agents\u002Fdomain-reviewer.md` for full criteria)\n**Goal:** Review the implementation for domain integrity — primitive obsession, leaky\nabstractions, missing domain types, naming, and **derivation-reached-at-every-call-site** (every\ncall site actually routes through the security\u002Fcorrectness derivation, handling real boundary\ninputs without failing open or closed). Has veto authority to send back to GREEN.\n\n### Phase 5: COMMIT\n\n**Hard gate — all conditions must be met:**\n\n1. Scoped affected-test set passes (the engine's dedicated aggregate gate and CI own broad verification, not each task)\n2. Linter passes (if tech-context specifies one — e.g., `bundle exec standardrb` for Rails)\n3. Type-check passes (if tech-context specifies a type-checker — e.g., `tsc --noEmit` \u002F\n   `npm run typecheck` for TypeScript). Already run as the Phase 4 pre-check; re-confirm clean here.\n4. Working tree is clean (no uncommitted changes outside this task)\n5. **Pre-diff sensitivity check** — for every NEW or CHANGED test in this task that claims to\n   cover new or changed behavior: create a temporary detached worktree at the base commit (`git worktree add --detach «tmp» «base»`), copy only the new or changed test files into it, run them there, then remove that temporary worktree with `git worktree remove --force «tmp»`.\n   Change no worktree's files beyond adding those copies, the temporary one included: never set\n   uncommitted work aside, and never discard, roll back or overwrite paths to reach the base\n   version. A test that still passes proves nothing\n   and will fail build_review's testQuality rubric one expensive lap later. A test that fails there\n   only because the new module is missing proves nothing either; apply the stub rule from RED. A value computed by the\n   test but never asserted on is an automatic fail of this check. Exempt: tasks under the\n   **No Legitimate RED for Already-Existing Behavior** and **Removal Boundary** sections, and\n   plan-declared `**Verify-only:** yes` tasks — their evidence forms replace this check.\n6. **Commit immediately** — do not defer commits to end of cycle or batch. Connection\n   interruptions lose uncommitted work. Commit as soon as GREEN passes and linter is clean.\n7. Commit with descriptive message referencing the behavior added\n8. **Commit includes Task trailer** — every commit in this cycle (feature, refactor, fixup)\n   carries `Task: \u003Cid>` with the bare plan header id (`### Task 7:` → `Task: 7`, never\n   `Task: task-7`). The commit-msg hook stamps it from `.pipeline\u002Fcurrent-task`; confirm it parsed.\n\n9. **Cross-boundary integration proved by its owning task.** When the current task owns a\n   cross-boundary integration check under `\u002Fplan` §3d, a test (new or existing) must exercise the\n   changed behavior through the appropriate project entry point named by that check—for example a\n   public API or route, CLI, job or worker, event consumer, framework hook, or application-service\n   boundary. A direct helper test alone cannot close that task. Tasks that do not own a changed\n   boundary remain at the lowest sufficient test layer; production-file count does not create\n   integration-test obligations.\n\n10. **Commit only to the current feature branch — never integrate upstream.** Do NOT run\n   `git fetch`, `git pull`, `git rebase`, or switch branches during the cycle. Mid-build\n   rebase onto a moved `origin\u002F\u003Cdefault>` rewrites history under active work. The only\n   sanctioned rebases run outside this loop.\n\n**After commit:** Return to RED for the next cycle. Stop only when every `Done when:` bullet,\nincluding each enumerated case and negative outcome, has a committed assertion you can cite.\n\n### Commit-less Completions: Evidence Trailers\n\nNot all tasks require code commits. Some tasks verify that existing behavior meets acceptance\ncriteria, and some have no implementation work (architectural decisions, etc.). Ordinary\ndocumentation maintenance is not a TDD task; `\u002Fexplore` delivers it directly.\nWhen a task completes without code changes, emit an empty commit with Evidence trailers.\n\nA plan task may carry a `**Verify-only:** yes` marker (see `skills\u002Fplan\u002FSKILL.md` §5d)\ndeclaring up front that it is expected to prove existing behavior already satisfies its\nacceptance criteria. Such tasks preferably complete via one of the two empty-commit\nEvidence forms below — `Evidence: satisfied-by \u003Csha>` when a prior commit already\nsatisfies the criteria, or `Evidence: skipped \u003Creason>` when there is no applicable\nsatisfying commit — rather than a code commit.\n\nEvidence forms MUST be emitted as `git commit --allow-empty` with the Evidence trailer in the\ncommit body; the engine reads commits only, not task reports.\n\n**Form 1: `Evidence: satisfied-by \u003Csha>`**\nUse when a task's acceptance criteria are already met by existing code (discovered during\npre-completion scan). Emit a no-op commit carrying the satisfying commit SHA:\n```\ngit commit --allow-empty -m \"chore(evidence): task criteria met\" \\\n  -m \"Task: 7\" \\\n  -m \"Evidence: satisfied-by abc123def456\"\n```\n\n**Form 2: `Evidence: skipped \u003Creason>`**\nUse when a task has no implementation work or is intentionally deferred. Emit a no-op commit\nwith a concise reason:\n```\ngit commit --allow-empty -m \"chore(evidence): task deferred\" \\\n  -m \"Task: 12\" \\\n  -m \"Evidence: skipped awaiting_stakeholder_input\"\n```\n\nEach empty commit carries `Task: \u003Cid>` plus one Evidence form; the conductor records the task as\ncompleted by verification rather than code delivery.\n\n### Memory Checkpoint (Per-Cycle, Conditional)\n\nAfter COMMIT, if this TDD cycle revealed any of the following, persist immediately:\n- **Category: `gotchas\u002F`** — An unexpected framework\u002Flibrary behavior that caused the test to fail for the wrong reason\n- **Category: `patterns\u002F`** — A new pattern established in this cycle that future cycles should follow\n\nMost cycles will NOT trigger a memory write — that is correct. Only persist genuinely surprising discoveries.\n\n### Refactoring\n\nRefactoring never happens during GREEN. It runs at batch boundaries through the `simplify` workflow\n(Claude `\u002Fsimplify`; Codex `$simplify`), in its own commits, and uses simplify's thresholds.\n\n### User-Requested Exit During TDD\n\nIf the user explicitly requests to stop, pause, or exit to the harness at any point during\na TDD cycle (RED, GREEN, DOMAIN, or COMMIT), the orchestrator MUST:\n\n1. **Do NOT commit incomplete work.** If the cycle is mid-flight (test written but no code,\n   or code written but domain review not passed), do not attempt to force a commit.\n\n2. **Write a halt marker** (`.pipeline\u002Fhalt-user-input-required`) with a one-line summary\n   of the in-flight cycle state (e.g., \"user requested exit; RED phase complete, awaiting GREEN\").\n\n### Structural Enforcement\n\nWhen dispatching through the selected host's available subagent facility, give each phase only\nthe context below — paths and metadata, not file contents. In Claude Code, this applies to Agent\ntool dispatches.\n\n| Phase | Agent | Provide in Prompt | Do NOT Provide |\n|-------|-------|-------------------|----------------|\n| RED | Generator | Task description, acceptance criterion text, test dir path, factory file path | Implementation files, other stories, full plan |\n| DOMAIN (post-RED) | Domain Reviewer | New\u002Fchanged test code (inline), list of existing domain types, **call-site list (`file:line`) for any security\u002Fcorrectness derivation in scope** | Full file tree, `.memory\u002F` files, other test files |\n| GREEN | Generator | Failing test output (inline), source dir path, 1-2 specific source files to modify | Test files, stories, plan |\n| DOMAIN (post-GREEN) | Domain Reviewer | New\u002Fchanged implementation code (inline), the test it satisfies (inline), **call-site list (`file:line`) for any security\u002Fcorrectness derivation in scope** | Full file tree, `.memory\u002F` files, other source files |\n| COMMIT | (main agent) | Full context | All files |\n\n**Context budget rules:**\n- **Provide file paths and metadata, not full contents.** Give subagents file paths, line\n  counts, and key method names\u002Fsignatures. Subagents read files themselves.\n- **For domain review: inline the diff only.** Paste the specific new\u002Fchanged code (the diff)\n  into the domain reviewer prompt — this is typically small (\u003C50 lines). Do NOT inline entire files.\n- **Name domain types that exist** (e.g., \"Domain types: Contact, Tag, ContactTag\") so the\n  domain reviewer doesn't scan the codebase.\n- **One criterion per RED dispatch** — the generator prompt contains exactly the acceptance\n  criterion being implemented, not the full story.\n- **Cap GREEN file access** — name the 1-2 files to modify, not the full source tree.\n- **Pre-gather decisions** — the TDD orchestrator checks `.memory\u002Fdecisions\u002F` for relevant\n  prior decisions and includes them in the domain reviewer prompt. The reviewer does not\n  search `.memory\u002F` itself.\n- **Reuse host-native implementer sessions for sequential tasks on same files.** When consecutive\ntasks modify the same files, continue the existing host-native session instead of spawning a new\none — this preserves the file cache and avoids redundant reads.\n\nThis isolation prevents the RED agent from peeking at implementation (biasing the test)\nand the GREEN agent from over-engineering beyond what the test requires.\n\n### Domain Reviewer Model Selection\n\nRight-size the model to the diff size to reduce API cost and rate limit pressure:\n\n- **In Claude Code, diffs under 50 lines:** dispatch with `model=\"sonnet\"` — sufficient for focused domain checks\n- **In Claude Code, diffs of 50+ lines:** dispatch with `model=\"opus\"` — deep analysis for larger changes\n- **Other supported hosts:** select the native equivalent of the same focused versus deep-review\n  capability; do not weaken the review boundary or veto authority.\n\n### Orchestrator Output Discipline\n\nBetween TDD phases, the orchestrator outputs ONLY:\n- The dispatch (silently — no announcement)\n- The subagent's structured response\n- A one-line status: `RED: FAIL (expected)` \u002F `GREEN: PASS` \u002F `DOMAIN: APPROVED` \u002F `DOMAIN: VETO — [reason]`\n\nNo narration, no explanation of what just happened, no preview of what comes next.\n\n### Test Coverage Rule: Behavior and Failure Boundaries\n\nCoverage follows the behavior or failure boundary being added, changed, or fixed — never a\none-to-one correspondence with production files. Choose the lowest sufficient test layer that\nproves the criterion. Use acceptance\u002Fsystem coverage only for a distinct multi-step externally\nobservable flow that cannot be proven sufficiently below it; do not duplicate lower-layer negative\nvariants or existing sufficient proof.\n\nNew behavior and bug fixes still begin with RED. A production-file change alone does not require a\nmirror test, and ordinary natural-language guidance does not create behavior to test. A declared\nexact replication still follows its full delta cycle and required scoped verification.\n\n## Verification\n\n- [ ] Test written BEFORE implementation and failed for the right reason\n- [ ] Domain review ran after RED and after GREEN\n- [ ] Scoped affected-test set, linter, and type-check (typed stacks) pass before commit\n- [ ] Pre-diff sensitivity check run for every new or changed behavioral test\n- [ ] Every new\u002Fchanged test file carries a resolvable `Covers:` marker for the active feature\n- [ ] Any cross-boundary integration check owned by this task is proven through its entry point\n- [ ] Working tree clean at commit; one behavior per cycle\n",{"name":5,"phase":43,"requires":44,"standalone":45,"description":7,"enforcement":35,"disable-model-invocation":45},"build",[],true,"main","60310a111655e2d63b87223befba464932465487","skills\u002Ftdd",2,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor","https:\u002F\u002Fgithub.com\u002Fjstoup111","2026-11-11 22:26:29",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":45},[55,58,61],{"tool":56,"command":57},"npx","npx skills add jstoup111\u002Fai-conductor --skill tdd",{"tool":59,"command":60},"bunx","bunx skills add jstoup111\u002Fai-conductor --skill tdd",{"tool":62,"command":63},"pnpm","pnpm dlx skills add jstoup111\u002Fai-conductor --skill tdd","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002FSKILL.md",[66,72,76,80,84],{"path":67,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":70,"sourceHtmlUrl":71},"agents\u002Fopenai.yaml","REFERENCE","参考文档",43,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Fagents\u002Fopenai.yaml",{"path":73,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":74,"sourceHtmlUrl":75},"references\u002Fdomain-review.md",2759,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Freferences\u002Fdomain-review.md",{"path":77,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":78,"sourceHtmlUrl":79},"references\u002Fdrill-down.md",1962,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Freferences\u002Fdrill-down.md",{"path":81,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":82,"sourceHtmlUrl":83},"references\u002Fgreen.md",2299,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Freferences\u002Fgreen.md",{"path":85,"resourceType":68,"resourceTypeDesc":69,"sizeBytes":86,"sourceHtmlUrl":87},"references\u002Fred.md",1996,"https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Ftdd\u002Freferences\u002Fred.md",[89,105,142,167,184,205],{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":38},"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",[],[43,96,97,98,99,32,28,100,101,102,26,103,104],"dependency hygiene","dependency","hygiene","build review dependency hygiene","diff","dependencies","license","judge","gating",{"skillNo":106,"name":107,"nameZh":6,"description":108,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":109,"categories":110,"keywords":124,"publishedAt":38},"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",[111,116,119],{"categoryNo":112,"categoryName":113,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000009","前端开发","SCENARIO","使用场景",{"categoryNo":117,"categoryName":118,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":120,"categoryName":121,"taxonomyType":122,"taxonomyTypeDesc":123},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[125,126,127,128,129,130,131,132,34,133,134,135,136,137,138,139,140,104,20,141],"writing","system","tests","writing system tests","projects","headless","project","end","frontend","acceptance","api","claims","directory","ui","framework","failing","request",{"skillNo":143,"name":144,"nameZh":6,"description":145,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":146,"categories":147,"keywords":148,"publishedAt":38},"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",[],[149,136,150,151,152,153,154,155,26,156,157,25,158,159,160,161,162,163,164,165,166,104,21],"verify claims","verify","do","adr","for","decision","claim","mechanics","only","workflow","code","reports","plan","active","questions","about","spec","invoke",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":173,"publishedAt":38},"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",[],[169,174,151,153,175,176,177,26,157,25,134,178,179,180,136,181,150,182,162,183,166,104,21],"conduct","decide","engineer","general","requirements","architecture","examples","artifact","requests","implementation",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":190,"publishedAt":38},"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",[],[191,192,193,24,136,194,195,196,150,28,197,198,199,200,201,26,202,157,25,203,21,204],"stack","land","stack land","evidence","child","changes","inspect","manual","correct","landing","safe","operator","confirmation","advisory",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":214,"publishedAt":38},"01M6K3DX3DTQ5MY3XDKDQ8K4JE","simplify","Use only at an active pipeline batch boundary after code has changed. Reviews current-batch duplication, complexity, over-engineering, and domain-modelling defects; do not invoke for ordinary refactors, code review, or requests that merely ask for simpler prose or code.","https:\u002F\u002Fgithub.com\u002Fjstoup111\u002Fai-conductor\u002Fblob\u002Fmain\u002Fskills\u002Fsimplify\u002FSKILL.md",[211],{"categoryNo":212,"categoryName":213,"taxonomyType":114,"taxonomyTypeDesc":115},"01JBSEEDCAT000000000000007","代码审查",[207,215,151,216,19,153,217,218,219,157,25,220,221,159,222,32,223,182,166,104],"complexity","reviews","pipeline","defects","code review","false","ask","batch","boundary"]