tdd-patternlisted

Use this skill whenever you are running as the `red` or `green` agent on an agile-team-v2 task. Covers the discipline-based spec isolation between red and green (no private TASK*.md files exist; the only handoff is committed code/tests), the in-scope vs out-of-scope rules of the red/green pattern (applies to standard and architectural complexity features only — mechanical maintenance is a mono-agent task), the mono-assistant safeguard when one Claude instance must wear both hats sequentially (commit red first, fresh session before reading green-side material — `check.sh` audits this at sprint review), and the marker-based task lookup procedure (grep for `TODO(impl-<slug>, ac-<NNN>)` to locate the scaffolded body and its sibling test file). Loaded only by `red` and `green`. Other agents (architect, PM, sprint-planner, e2e-tester, reviewer, bug-detective) operate outside the live red/green isolation flow and do not need these rules.
JLugagne/claude-skills · ★ 0 · Testing & QA · score 72

Install: claude install-skill JLugagne/claude-skills

# TDD pattern — red and green discipline The strict TDD workflow paired teammates run for `standard` and `architectural` complexity features in agile-team-v2. This skill captures the rules that *only* apply to red and green, so they can be removed from the global `agile-project` skill (which every agent loads). If you are reading this and you are not red or green: stop. You don't need this skill. The high-level "Red/Green pattern — ABSOLUTE RULE" stub in the `agile-project` skill is enough for context. --- # Spec isolation — by discipline, not by file In v2 there are no `TASK.md`, `TASK-red.md`, or `TASK-green.md` files. Both red and green find their work via the inline marker `TODO(impl-<slug>, ac-<NNN>)` in the production code, looked up via `grep`. There is no private spec for either side; isolation is preserved by **discipline**, audited by `check.sh` and by the reviewer's pass DoD post-mortem. ## What red reads - The `// AC: <description>` comment immediately above the scaffolded body that the architect inlined. - The scaffolded function or method signature itself (parameters, return types, receiver). - For business tests (when the matching test skeleton in `pm_test_territories` carries a `// SCENARIO:` marker placed by the PM): that scenario line. - Applicable DECISIONS and ADRs listed in FEATURE.md `## Relevant decisions`. - FEATURE.md `# User journey` for context (when `// AC:` or `// SCENARIO:` on its own is too short). - Existing test files in the same packag