メニュー
Implement features using strict Red-Green-Refactor TDD cycle. No production code without a failing test first. Use when: implementing behavior where tests can define expected outcomes before production code changes.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Read-only cross-artifact consistency analysis after planning and before approval. Verifies that spec.md, requirements.json, plan.md, tasks/Tn.md, traceability.json are mutually consistent: no duplicate/ambiguous requirements, every behavior mapped to a task, no orphan tasks, no coverage gaps, no contradictions. Outputs artifact-analysis.json with coverage% and severity. CRITICAL/HIGH findings block the approval gate. Use when: planning produced plan.md + tasks + traceability.json, before the user approves the plan.
Explore 2-3 implementation options with trade-offs when the user describes a new feature or requirement. Use when: the user asks for a new feature design, implementation options, or technical trade-off analysis.
After implementation and before final verification, compare current code/tests against the intent inventory (requirements.json + traceability.json). Classify each requirement/behavior as covered, missing, partial, contradicts, or unrequested. Append missing/partial/contradicts as new tasks back to executing. Repeat until converged: zero blocker findings. Outputs convergence-report.json. Use when: executing produced test-report.md but before loom-verification-before-completion.
Expand each requirement into verifiable Behavior Obligations across 15 fixed dimensions (happy-path, boundary, invalid-input, authorization, state-transition, idempotency, concurrency, atomicity, external-failure, compatibility, security, performance, observability, recovery, forbidden-behavior) before planning. Use when: brainstorming produced requirements.json and spec is approved, but behaviors are still placeholders or only happy-path; before loom-writing-plans.
Read-only adversarial reviewer that looks for what SHOULD exist but doesn't, by cross-checking Behavior Obligations against code, tests, expected side effects, forbidden side effects, failure scenarios, and public API changes. Focuses on negative space: events that should not repeat, permissions that should not be bypassed, partial writes that should not happen, old APIs that should not change, swallowed exceptions, leaked secrets. Outputs findings.json. Use when: executing or converge needs an independent omission sweep.
Analyze user request + collect signals (file scope, keywords, worktree state, spec existence), then select pipeline steps via rule short-circuit / AI fallback / rule-based fallback. Select steps first, expose the choice to the user, and persist selected dynamic_steps only after explicit user confirmation; pipeline-plan.md is optional for manual review. Use when: user is unsure which pipeline type to pick, or wants AI to choose steps automatically.
| name | loom-test-driven-development |
| description | Implement features using strict Red-Green-Refactor TDD cycle. No production code without a failing test first. Use when: implementing behavior where tests can define expected outcomes before production code changes. |
| when_to_use | Implement behavior through a strict red-green-refactor TDD loop. |
| argument-hint | <behavior or test seam> |
| user-invocable | true |
红（Red）→ 绿（Green）→ 重构（Refactor）
默认用于新功能、bug 修复、重构和行为变更。一次性原型、生成代码或纯配置变更可以先询问用户是否例外。
当前 task 的需求产物必须从 specs/<date+feature>/ 读取；不要在项目根目录读取或生成 spec.md、plan.md、tasks/ 等 loom 阶段产物。
读取 specs/<date+feature>/spec.md、specs/<date+feature>/plan.md 和当前 specs/<date+feature>/tasks/TN.md，明确当前 task 的测试范围。
写测试前先列出候选 seam，并说明每个 seam 对应的 public boundary，例如 CLI 命令、HTTP API、组件交互、公开函数、持久化副作用或事件输出。
必须向用户或当前已批准 spec/plan 对齐以下内容：
未确认 seam 时，不得写测试。若用户不在场且 spec/plan 已明确 public boundary，可基于已批准产物确认 seam，并在输出中记录依据。
测试立即通过说明测了已有行为；修正测试。
写最少代码让测试通过，只实现当前测试覆盖的行为。不要顺手扩展功能、重构无关代码或添加未来配置。
仅在测试绿色后重构。消除重复、改善命名，并重新运行相关测试。需要时执行 constitution.md 中的 BUILD_CMD、VET_CMD、TEST_CMD。
对下一个行为点重复红绿重构。
示例、理由和反模式见：
references/examples-and-rationale.mdreferences/testing-anti-patterns.mdreferences/common-excuses.md出现红旗时，删除未验证实现，从红开始。
生产代码 -> 测试存在且先失败
否则 -> 不是 TDD