features.json を読み込み、pending な機能を1件ずつ tdd-guide エージェント（内部で tdd-cycle を使用）で実装するスキル。
Context anxiety（トークン上限接近による焦り）と Context rot（情報劣化）を防ぐため、 機能単位のループ・状態管理・implementation-notes.md への記録を担う。builder エージェントが実装フェーズを開始するときは必ずこのスキルを呼ぶ。
インストールする前に、エージェントに与えられる指示の中身を確認できます。
1機能 = 1サイクル。完了を急がない。
Context anxiety の根本は「未完了なのに完了と言いたくなる焦り」。 このスキルは機能を小さな単位に分割し、各機能の完了を数値で示すことで焦りを排除する。 「全て完了しました」は禁止。「feat-N/M 完了」だけが許可された完了報告。
LOAD → PICK → TDD → RECORD → CHECK → NEXT
↑__________________________________|
features.json を Read する
Read("features.json")
issue-plan スキルで features.json を生成してください」と報告し、スキルを終了する。implementation-notes.md を確認する
Read("implementation-notes.md") // 存在する場合のみ
未実装 feature を特定する
status: "pending" の feature を phase → 依存関係の順に並べるdependencies に含まれる feat の status がすべて "done" でない feature はスキップするfeatures.json の dependencies を見直してください」と報告し、スキルを終了するskill-usage.json を初期化する（存在しない場合のみ）
.claude/orchestrate/skill-usage.json が存在するか確認する。
存在しない場合、以下の内容で Write する:
{
"version": "1.0",
"created_at": "[ISO8601]",
"updated_at": "[ISO8601]",
"invocations": []
}
LOAD 完了を報告する
[build-cycle] LOAD 完了
合計: N 機能 | 完了: X 機能 | 残り: Y 機能
次の実装対象: feat-XXX「機能名」
最初の status: "pending" かつ dependencies が満たされた feature を選択する
features.json の該当 feature の status を "in_progress" に更新する
{ "status": "in_progress" }
PICK 完了を報告する
[build-cycle] feat-XXX「機能名」を開始します
acceptance_criteria: N 件
tests.unit: N 件 / tests.integration: N 件
dependencies: [feat-YYY（完了済み）]
tdd-guide エージェントを起動する
feature の情報をプロンプトに渡す:
Agent({
subagent_type: "tdd-guide",
prompt: `
feat-XXX: [feature.title]
## 実装対象ファイル
新規作成: [feature.files.create]
変更: [feature.files.modify]
## 受け入れ条件
[feature.acceptance_criteria の各項目を箇条書き]
## テスト戦略
### Unit Tests
[feature.tests.unit の各テスト名・説明]
### Integration Tests
[feature.tests.integration の各テスト名・説明]
### E2E Tests
[feature.tests.e2e の各テスト名・説明（空の場合は省略）]
`
})
tdd-guide の完了を待つ
tdd-guide（内部で tdd-cycle を使用）が 🔵 REFACTOR完了 を報告するまで待機する。
tdd-guide がエラーを報告した場合: そのエラー内容を記録してユーザーへ報告し、このスキルを一時停止する。
features.json の該当 feature の status を "done" に更新する
{ "status": "done" }
implementation-notes.md に記録を追記（append）する
## feat-XXX: [feature.title]
- **実装日時:** YYYY-MM-DD
- **実装ファイル:**
- 新規: [feature.files.create]
- 変更: [feature.files.modify]
- **テスト結果:** N 件 PASS
- **acceptance_criteria:**
- [x] 条件1
- [x] 条件2
- **次の機能:** feat-YYY（または「なし（最終機能）」）
RECORD 完了を報告する
[build-cycle] feat-XXX「機能名」実装完了
進捗: X/N 機能完了
implementation-notes.md を更新しました
features.json の context_checkpoints を確認する
現在完了した feat-XXX が checkpoints に登録されているか確認する。
登録されている場合: checkpoint に定義された save_artifacts が最新か確認する。
コンテキスト長の主観的評価
応答が長くなってきたと感じる場合、または処理した機能数が多い場合は以下を実行する:
CHECK 完了（問題なければ次フェーズへ）
残りの status: "pending" feature を確認する
全機能完了の報告
[build-cycle] 全 N 機能の実装が完了しました
完了: N/N 機能
implementation-notes.md に全記録を保存済み
次のステップ: orchestrator に報告し、Review フェーズへ進んでください
tdd-cycle スキルがコンテキスト圧縮前に tdd-progress.md を書き出した場合:
| 状況 | 対応 |
|---|---|
| features.json が存在しない | ユーザーへ issue-plan スキル実行を依頼し、スキル終了 |
| dependencies 未完了の feature のみ残っている | ユーザーへ報告（循環依存の可能性） |
| tdd-cycle がエラーを報告 | エラー内容を記録して一時停止。ユーザーへ報告 |
| テストが5回試行後もパスしない | ユーザーへ報告し、手動対応を求める |
まだレビューはありません。使ってみた感想をお寄せください。
概要と使いどころ
テストカバレッジのギャップを体系的に分析し、実際に動くテストコードを提案するスキル。 以下のようなときに使う： - テストカバレッジを改善したい・不足テストを特定したい - 「テストが足りない」「カバレッジを上げたい」「どこをテストすべき」 - 「未テストの関数」「what tests am I missing」「improve test coverage」「coverage gap」 t-wada式TDDの原則に基づき、テストの抜け漏れを特定して優先度付きで補完する。 引数: 分析対象ファイル・ディレクトリ（省略時はプロジェクト全体）
フレーキーテスト（不安定なテスト）を検出・分類・修正支援するスキル。 以下のような状況で使う： - 「テストが時々失敗する」「CI が時々落ちる」 - 「同じコードなのにテスト結果が変わる」 - 「flaky test」「不確定」「再実行すると通る」 - 「テストが不安定」「テストの信頼性が低い」 t-wada式TDDの信頼性基盤を守るために使用する。 引数で実行回数を指定可能（デフォルト: 5回）。
Uncorrelated Evaluator — 4軸ルーブリック専門エージェント（functionality-reviewer・code-reviewer・design-reviewer・originality-reviewer）と security-reviewer を5並列実行し、成果物を多面的に独立評価します。PASS / NEEDS WORK / BLOCKED 判定を返します。Self-leniency 防止のため、実装エージェントのコンテキストを引き継がない新規エージェントとして起動します。「レビューして」「評価して」「実装を確認して」などのリクエストで起動します。
Iteratively detects and auto-fixes technical debt in a codebase using three quality criteria from debt-analysis references: conditional branch simplification, encapsulation, and separation of concerns. Applies fixes directly to code, runs existing tests to verify no regressions, re-analyzes, and loops until all high-severity issues are resolved or max iterations (5) reached. Use this skill when you want to automatically improve code quality with real code changes, reduce technical debt systematically, or clean up code to meet quality standards. Trigger on phrases like "fix technical debt", "clean up code quality", "refactor and fix issues", "improve code quality automatically", "apply debt fixes", "fix code problems", "eliminate debt".
日本語の概要は準備中です。原文の説明を表示しています。
任意のタスク（GitHub Issue・自由記述リクエスト・口頭要件）を起点に、受け入れ条件確認・スコープ定義・影響分析・テスト戦略を含む実装計画（15セクション）と、builder エージェントへ渡す features.json を生成します。「〇〇を作って」「実装計画を作って」「Issue
Planner→Builder→EvaluatorのLong-Runningエージェントハーネスで複雑なタスクを実装します。plannerがfeatures.jsonに機能を分解し、builderがTDDで1機能ずつ実装し、evaluatorがPASSするまでbuilderを繰り返します。「〇〇を作って」「実装して」「long-running」などのリクエストで起動します。