菜单
t-wada式TDD（テスト駆動開発）でRED→GREEN→REFACTORサイクルを使ってテストファーストで開発を進めるスキル。 ユーザーが「TDDで実装して」「テストファーストで」「t-wada式で」「REDから始めて」「失敗するテストを先に」と言った場合は必ずこのスキルを使うこと。 FizzBuzz、スタック、認証、バリデーションなど、あらゆる実装タスクにTDDアプローチを適用できる。 ユーザーが実装を始めようとしているときは積極的にTDDを提案すること。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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".
features.json を読み込み、pending な機能を1件ずつ tdd-guide エージェント（内部で tdd-cycle を使用）で実装するスキル。 Context anxiety（トークン上限接近による焦り）と Context rot（情報劣化）を防ぐため、 機能単位のループ・状態管理・implementation-notes.md への記録を担う。 builder エージェントが実装フェーズを開始するときは必ずこのスキルを呼ぶ。
テストカバレッジのギャップを体系的に分析し、実際に動くテストコードを提案するスキル。 以下のようなときに使う： - テストカバレッジを改善したい・不足テストを特定したい - 「テストが足りない」「カバレッジを上げたい」「どこをテストすべき」 - 「未テストの関数」「what tests am I missing」「improve test coverage」「coverage gap」 t-wada式TDDの原則に基づき、テストの抜け漏れを特定して優先度付きで補完する。 引数: 分析対象ファイル・ディレクトリ（省略時はプロジェクト全体）
Uncorrelated Evaluator — 4軸ルーブリック専門エージェント（functionality-reviewer・code-reviewer・design-reviewer・originality-reviewer）と security-reviewer を5並列実行し、成果物を多面的に独立評価します。PASS / NEEDS WORK / BLOCKED 判定を返します。Self-leniency 防止のため、実装エージェントのコンテキストを引き継がない新規エージェントとして起動します。「レビューして」「評価して」「実装を確認して」などのリクエストで起動します。
フレーキーテスト（不安定なテスト）を検出・分類・修正支援するスキル。 以下のような状況で使う： - 「テストが時々失敗する」「CI が時々落ちる」 - 「同じコードなのにテスト結果が変わる」 - 「flaky test」「不確定」「再実行すると通る」 - 「テストが不安定」「テストの信頼性が低い」 t-wada式TDDの信頼性基盤を守るために使用する。 引数で実行回数を指定可能（デフォルト: 5回）。
任意のタスク（GitHub Issue・自由記述リクエスト・口頭要件）を起点に、受け入れ条件確認・スコープ定義・影響分析・テスト戦略を含む実装計画（15セクション）と、builder エージェントへ渡す features.json を生成します。「〇〇を作って」「実装計画を作って」「Issue
| name | tdd-cycle |
| description | t-wada式TDD（テスト駆動開発）でRED→GREEN→REFACTORサイクルを使ってテストファーストで開発を進めるスキル。 ユーザーが「TDDで実装して」「テストファーストで」「t-wada式で」「REDから始めて」「失敗するテストを先に」と言った場合は必ずこのスキルを使うこと。 FizzBuzz、スタック、認証、バリデーションなど、あらゆる実装タスクにTDDアプローチを適用できる。 ユーザーが実装を始めようとしているときは積極的にTDDを提案すること。 |
t-wada式TDDの核心は「テストが仕様書」という考え方。コードを書く前にテストを書くことで、 設計を明確にし、過剰実装を防ぎ、リファクタの安全網を得る。
Fake it till you make it: GREEN フェーズでは恥ずかしいほど単純なコード（ハードコードも可）で構わない。 三角測量（Triangulation）で徐々に汎化させる。
RED → GREEN → REFACTOR → RED → ...
↑___________________________|
各フェーズで必ずテストを実行し、期待通りの色（RED/GREEN）を確認してから次へ進む。
要件を1つ選ぶ: 最も小さく具体的な振る舞いを1つ選ぶ。複数の要件を一度にテストしない。
テストを書く: まだ存在しない関数・クラスを呼び出すテストを書く。
テストを実行して失敗を確認する: 必ずテストを実行し、期待通りに失敗することを確認する。
ImportError や NameError で失敗するのは正常（まだ実装がないため）ユーザーに RED を報告する:
🔴 RED
テスト: [テスト名]
失敗理由: [エラーメッセージ]
次: GREENフェーズでテストをパスさせます
skill-usage.json に RED ログを追記する:
.claude/orchestrate/skill-usage.json が存在する場合、invocations 配列に追記する:
{
"id": "inv-XXX",
"timestamp": "[ISO8601]",
"skill": "tdd-cycle",
"caller": "tdd-guide",
"feature_id": "[feature_id（不明なら 'unknown'）]",
"phase": "RED",
"test_name": "[テスト名]",
"result": "FAIL",
"error": "[失敗理由]"
}
ファイルが存在しない場合はスキップする（build-cycle の LOAD フェーズが初期化する）。
テストをパスさせるための最小限のコードだけを書く。それ以上書かない。
⚠️ Context anxiety 対策: 全テストが GREEN になるまで「完了」とユーザーに報告してはならない。 コンテキストが長くなった場合は現在のサイクル状態（どのテストがRED/GREEN/未着手か）を
tdd-progress.mdに書き出してから/compactすること。
「最小限」とは本当に最小限。最初は定数を返すだけでよい。「このコードは恥ずかしい」と感じるくらいがちょうどよい。 それが Fake it の精神。恥ずかしいコードを書くことで、次のテストが追加の動機となって自然に汎化される。
| 状況 | ❌ NG（完成形） | ✅ OK（Fake it） |
|---|---|---|
| 数値返し | if n%15==0: return "FizzBuzz" ... | return "1" |
| boolean返し | return len(self._items)==0 | return True |
| オブジェクト操作 | self._items.append(item); return sum(...) | return 0 |
最初のテストが1つしかないなら、その1つを通す最もシンプルなコードでよい。次のテスト（三角測量）が追加されたとき初めて汎化を強制される。
完成形を先に書くのは、見た目はTDDでも三角測量が機能しない。1テスト→最小実装→次のテストで汎化、を厳守する。
ベタ書きから始める（Fake it）: ハードコードした値を返すだけのコードを書く。 テストが1つしかないなら、その1つをパスさせる最もシンプルなコードでよい。
テストを実行してパスを確認する: 必ずテストを実行し、GREEN になったことを確認する。
ユーザーに GREEN を報告する:
✅ GREEN
テスト: [テスト名]
実装: [書いたコードの概要]
次: REFACTORするか、次のREDに進みます
skill-usage.json に GREEN ログを追記する:
.claude/orchestrate/skill-usage.json が存在する場合、invocations 配列に追記する:
{
"id": "inv-XXX",
"timestamp": "[ISO8601]",
"skill": "tdd-cycle",
"caller": "tdd-guide",
"feature_id": "[feature_id]",
"phase": "GREEN",
"test_name": "[テスト名]",
"result": "PASS",
"implementation": "[実装コードの概要（1行）]"
}
リファクタの必要性を判断する: GREEN になったコードを見て、以下を確認する。
fix-debt と flaky-test-detect を並列実行する: GREENになったファイルに対して両スキルを同時に呼び出す。
| スキル | 対象 | 目的 |
|---|---|---|
fix-debt | プロダクションコード | 条件分岐・カプセル化・関心の分離の3基準で技術的負債を検出・自動修正 |
flaky-test-detect | テストコード | フレーキーテストを検出し、TIMING/GLOBAL_STATE等のパターンに分類して修正 |
fix-debt はリグレッションが出た修正を自動リバートflaky-test-detect は検出したフレーキーテストを修正し、再度テストを実行して安定を確認小さく変更し、その都度テストを実行する: fix-debt で対応できない軽微な問題（命名・マジックナンバー等）は手動で修正する。1変更ごとにテストを実行して GREEN を保つ。
テストコード自体もリファクタ対象: プロダクションコードと同様に、テストコードも整理する。
ユーザーに REFACTOR 結果を報告する:
🔵 REFACTOR完了
変更内容: [リファクタの概要（fix-debtの適用内容を含む）]
テスト: 全パス
次: 次の要件のREDフェーズへ
skill-usage.json に REFACTOR ログを追記する:
.claude/orchestrate/skill-usage.json が存在する場合、invocations 配列に追記し updated_at も更新する:
{
"id": "inv-XXX",
"timestamp": "[ISO8601]",
"skill": "tdd-cycle",
"caller": "tdd-guide",
"feature_id": "[feature_id]",
"phase": "REFACTOR",
"changes": "[fix-debt・flaky-test-detect の適用内容（1行）]",
"result": "PASS"
}
Fake itで汎化しきれていない場合は、coverage-gap スキルを使って追加すべきテストを特定し、汎化を強制する。
完了基準: ユーザーが指定した全ての振る舞いのテストが GREEN になり、各フェーズの REFACTOR が完了したら TDD セッション完了とする。
coverage-gapによる三角測量は Fake it で汎化しきれていないと判断した場合にのみ使用し、必須ではない。
coverage-gap で未カバー箇所を特定する: 現在実装したファイルを対象に coverage-gap スキルを呼び出す。
追加テストを RED で確認する: coverage-gap が提案したテストを RED フェーズとして追加する。
汎化した実装で GREEN にする: ハードコードを取り除き、全テストが通る実装に更新する。
サイクルを繰り返す: coverage-gap を再実行して残った未カバー箇所がなくなるまで繰り返す。
# テスト1: add(1, 1) == 2 → return 2 で Fake できてしまう
# ↓ coverage-gap を実行 → "add(a, b) の a≠b のケースが未カバー" と報告
# テスト2: add(2, 3) == 5 → これで return a + b を強制される
coverage-gap → RED → GREEN → REFACTOR → coverage-gap の繰り返しで、
カバレッジデータが三角測量の「何を次にテストすべきか」を客観的に示す。
| 言語 | フレームワーク | コマンド |
|---|---|---|
| Python | pytest | pytest -v [test_file] |
| TypeScript/JS | vitest | npx vitest run [test_file] |
| TypeScript/JS | jest | npx jest [test_file] |
| Go | testing | go test ./... |
| Rust | cargo test | cargo test |
テスト実行コマンドが不明な場合はユーザーに確認する。
ユーザーが「〇〇を実装したい」「〇〇を書こうと思ってる」と言ったとき、TDDを提案する。
提案テンプレート:
〇〇の実装、よければt-wada式TDD（テスト駆動開発）で進めてみませんか？
最初に「最も単純なテスト1つ」を書くことで仕様が明確になり、過剰実装を防げます。
例えば最初のテストはこんなイメージです：
def test_[最も簡単なケース]():
[最小の準備]
assert [期待する結果]
これをREDから始めてよいですか？テストフレームワークはpytestでよいですか？
ユーザーが同意したらセッションの始め方へ進む。断られたら通常の実装支援に切り替える。
ユーザーが「TDDで実装して」と漠然と言ったときは、「まず最も単純な入力と期待する出力を1つ教えてください」と聞くと、最初のテストが具体化される。