| name | tdd-cycle |
| description | RED-GREEN-REFACTOR オーケストレーター。メイン Claude が Skill ツール経由で /red-test → /audit-tests → /implement → /verify-test → /simplify → /verify-test の順に実行し、各フェーズは独立 fork コンテキストで動く。全ループに明示的な上限あり。 |
TDD Cycle — Main Claude Orchestrator 版
⚠️ DEPRECATED (1.3.0+) — 新規プロジェクトでは /generate <story-id> を推奨します。
H-Consensus モデルでは、/tdd-cycle と /ticket-cycle の 2 レーンは /generate に統合されました。/generate の T2 (medium tier) 分岐は本スキルと同等の RED → IMPLEMENT → VERIFY フローを実行し、T3 (high tier) ではさらに test-auditor と review-impl が追加で fork されます。
このスキルは 既存プロジェクトの後方互換のためのみに残存しています。単発で TDD サイクルだけ回したい場合 (Sprint Contract 交渉を経由せずに) は引き続き利用可能です。
新規プロジェクトでは /planning → /generate <story-id> のフローに切り替えてください。
Usage
/tdd-cycle <要件>
このスキルはメイン Claude に「TDD orchestrator として動作せよ」と指示する指示書である。
メイン Claude は Skill ツール経由で /red-test / /audit-tests / /implement / /verify-test を順に呼び出す。各サブスキル側の context: fork 指定により、tester / test-auditor / implementer は独立コンテキストで孫エージェントとして起動する。orchestrator 自身はメイン会話コンテキストに居座ったまま、各フェーズの判定レポートを元に次の Phase を決定する。
この設計の利点:
- orchestrator が親に居座るので、ユーザーへの途中報告・承認ゲート・割り込みがそのまま機能する
- Generator 側（tester / implementer）だけが fork されるため、相互のコンテキスト汚染を遮断しつつ、親コンテキストは判定レポートのみを保持する（メイン肥大化を防ぐ）
Task
あなた（メイン Claude）は TDD orchestrator です。
Skill ツールで各サブスキルを順に呼び出し、出力を判定して次の Phase を決定してください。
共通ルール
- 成功時は自動的に次の Phase に進む（ユーザー確認を都度挟まない）
- 失敗時のみユーザーに報告して指示を仰ぐ
- Skill ツール呼出が失敗した場合（タイムアウト・エラー・想定外フォーマット）、即座にユーザーに報告して中断
- テストファイルは変更しない（tester が書いたテストが正）
- テストより先に本番コードを書いた場合 → 削除してテストからやり直す
Step 1: RED & AUDIT
まず Skill ツールで /red-test $ARGUMENTS を呼び出す。tester 孫エージェントが fork コンテキストで起動し、要件に基づいてテストファイルを作成、Judgment: RED（全テスト失敗）を確認して戻る。
続けて Skill ツールで /audit-tests $ARGUMENTS を呼び出す。test-auditor 孫エージェントが fork コンテキストで起動し、AC カバレッジ確認 + 報酬ハック検出（構文パターン + 意味的分析）を行い、Verdict: PASS / NEEDS_IMPROVEMENT を返す。
/audit-tests の出力を解析し、以下を判定:
1-A. PASS の場合
さらに以下の受理条件をすべて満たしているか確認:
- AC Coverage 完全性:
❌ Missing が1つもない
- 意味的分析の実施: Semantic Analysis Findings セクションが含まれている
- Confidence 確認: Confidence: HIGH または MEDIUM（LOW なら 1-B のループに進む）
すべて満たす → Step 2 へ進む
受理条件を満たさない → 1-B のループに進む（現在の実行を試行回数 1 として扱う）
1-B. NEEDS_IMPROVEMENT または受理拒否の場合
最大3回まで以下を試行（1回目は Step 1 冒頭で既に実行済み、2-3 回目を以下で再試行）:
for 試行 in 2..3:
Skill ツールで /red-test を再実行（補強指示を $ARGUMENTS に追加：未カバー AC、報酬ハック指摘への対応等）
Skill ツールで /audit-tests を再実行
if PASS かつ受理条件を満たす:
break → Step 2
3回試行しても改善しない場合:
- エスカレーションポリシーに従い、Handoff Document を出力してユーザーにエスカレーション
- 含めるべき情報: 各試行の AUDIT Report、未カバーの AC、検出された報酬ハックパターン、推奨アクション
Step 2: IMPLEMENT
Skill ツールで /implement $ARGUMENTS を呼出（$ARGUMENTS に要件を渡す）。
implementer 孫エージェントが fork された独立コンテキストでテストを通す最小限の実装を作成し、Judgment: GREEN / RED を返す。
Step 3: VERIFY
Skill ツールで /verify-test を呼出。
tester 孫エージェントが fork された独立コンテキストで全テストを実行し、Judgment: PASS / FAIL を返す。
3-A. PASS の場合
Step 4 へ進む。
3-B. FAIL の場合
最大3回まで以下を試行:
for 試行 in 1..3:
Skill ツールで /implement を再実行（失敗テスト情報を $ARGUMENTS に追加）
Skill ツールで /verify-test を再実行
if PASS:
break → Step 4
3回試行しても FAIL の場合:
- エスカレーションポリシーに従い、Handoff Document を出力
- 含めるべき情報: 失敗したテスト一覧、各試行の実装内容、推測される根本原因、推奨アクション
Step 4: SIMPLIFY
Skill ツールで /simplify を呼出。simplify スキル側に context: fork が無いため、親（orchestrator）コンテキストでそのまま実行され、コード変更を直接行う。テストが通っている状態なので、安全にリファクタリングできる。
Step 5: VERIFY (再確認)
Skill ツールで /verify-test を再度呼出。simplify で壊れていないことを確認する。
5-A. PASS の場合
完了。Final Output を出力する。
5-B. FAIL の場合
最大2回まで以下を試行:
for 試行 in 1..2:
simplify の変更を git で revert
別のリファクタリング戦略で再度 Skill ツールで /simplify を試行
Skill ツールで /verify-test を再実行
if PASS:
break → 完了
2回試行しても FAIL の場合:
- すべての simplify 変更を revert（テストが通る状態に戻す）
- エスカレーションポリシーに従い、Handoff Document を出力
- 含めるべき情報: simplify で何を試したか、なぜ FAIL したかの推測、推奨アクション
エスカレーションポリシー
すべてのループ上限到達時、以下の Handoff Document を出力してユーザー判断を仰ぐ:
## TDD Cycle Escalation
### Phase: [どのフェーズで止まったか]
### Attempts: [何回試行したか]
### Failures
- 試行1: [何を試したか] → [結果]
- 試行2: ...
### Root Cause Hypothesis
[なぜ全部失敗したかの推測]
### Recommended Action
[ユーザーに何をしてほしいか]
ユーザーからの明示的な指示があるまで続行しない。
Skill ツールエラー処理
各 Skill ツール呼出（/red-test, /audit-tests, /implement, /verify-test, /simplify）が以下のいずれかの場合:
- タイムアウト
- 例外エラー
- 想定外の出力フォーマット
- 結果が空
→ 即座にユーザーに報告して中断。再試行を勝手に繰り返さない。
理由: Skill ツール自体のエラーは TDD ロジックの問題ではなく、環境やインフラの問題の可能性が高い。エージェントが判断で再試行するのは無駄。
Rules
- Git commit per feature —
feat: [Feature Name] 形式
- テストを通す実装ができたら即コミット。大きな変更をためない
- 全テスト PASS を確認してからコミット
- すべてのループに明示的な上限あり。暗黙の無限ループは存在しない
Context Degradation — 監視
長時間の実装セッションで以下の兆候が出たら、現在のタスクを完了後に停止する:
- Repetition — 同じコードの再生成、同じ説明の繰り返し
- Skipping — 仕様にある機能のスキップ
- Quality drop — エラーハンドリングの欠落、命名の不統一
- Premature completion — 「完了」宣言だが未実装機能が残っている
検知時は以下の Handoff Document を出力してユーザーに報告:
## Context Handoff
### Progress
- [x] Feature 1 — committed
- [ ] Feature 3 — IN PROGRESS: [state]
- [ ] Feature 4 — NOT STARTED
### Remaining Tasks
[未完了のタスク一覧]
### Build Status / Known Issues
Iteration Mode（QA 修正フロー）
acceptance-tester やレビューから修正指示を受けた場合の手順:
- 根本原因調査 — QA Report の issue を読み、まず原因を特定する
- 修正計画 — 場当たり修正ではなく、根本的な修正を設計する
- TDD で修正 — 再発防止テストを先に書いてから修正（/red-test → 修正 → /verify-test）
- 回帰チェック — 全テスト実行の出力を表示。テスト数が減少していないことを確認
- Critical Issues first → Improvements → Minor
- 既存機能をリグレッションしない
回帰ベースライン
修正前のテスト実行結果（テスト数・成功数）を記録しておく。
修正後の /verify-test で以下を確認:
- テスト数が減少していないこと
- 前回 PASS だったテストが FAIL になっていないこと
回帰発見時は修正を中止し、根本原因を再調査する。
Final Output
全機能実装完了後の出力:
- File tree
git log --oneline- Build status（clean であること）
- Test results — 全テスト実行の完全な出力（テスト数・成功数・失敗数）
- Run instructions（アプリの起動方法）
Next
→ /verify-local → /smart-commit → 次の機能があれば /tdd-cycle、全機能完了なら /e2e-evaluate
Gotchas
<!-- post-mortem agent appends entries here -->
<!-- Format: - [HASH8] [YYYY-MM-DD] : (hits: N, source: T-XXXX) -->
