메뉴
機能実装、バグ修正、コード変更を行う際に使用。新機能の実装、バグ修正、既存コードの変更、振る舞いを伴うリファクタリング時にトリガーされる。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
実装完了後のコードレビューに使用。仕様準拠・コード品質・セキュリティの3観点を並列レビューし、指摘を依存解決して修正する。
セッション完了後の振り返りに使用。ワークフロー遵守の検証、ユーザ指摘の収集と自己改善提案、改善後のリグレッション確認を行う。
ワークフローを開始する。ユースケースを選択し、適切なステップを順に実行する
設計確定後、実装前に使用。設計をタスクに分解し、実装順序と依存関係を明確にする。
大規模プロジェクト（複数機能・フェーズ分割が必要）で使用。全体をフェーズに分割し、マイルストーンとリスクを定義する。各フェーズは planning スキルに渡す。
機能開発・バグ修正の着手前に使用。メインセッションで人間パートナーと対話し、要件を構造化する。コード調査は Explore エージェントに委譲。
| name | tdd |
| description | 機能実装、バグ修正、コード変更を行う際に使用。新機能の実装、バグ修正、既存コードの変更、振る舞いを伴うリファクタリング時にトリガーされる。 |
テストを先に書く。失敗を確認する。テストを通す最小限のコードを書く。
入力: REQ パス（例: requirements/REQ-001/）+ 承認済みの requirements.md 全文（+ design.md があればそれも）
出力: テスト全 GREEN の実装コード + テストコード
原則: テストが失敗するのを見ていないなら、そのテストが正しいものをテストしているかは分からない。
失敗するテストなしにプロダクションコードを書くな
テストより先にコードを書いた？ 削除しろ。最初からやり直せ。
振る舞いの変更には実行可能な検証が必要。
常に:
例外（人間パートナーに確認すること）:
「今回だけ TDD をスキップ」と思った？ それは合理化だ。やめろ。
digraph tdd_cycle {
rankdir=LR;
red [label="RED\n失敗するテストを書く", shape=box, style=filled, fillcolor="#ffcccc"];
verify_red [label="正しく失敗\nするか確認", shape=diamond];
green [label="GREEN\n最小限のコード", shape=box, style=filled, fillcolor="#ccffcc"];
verify_green [label="通るか確認\n全てグリーン", shape=diamond];
refactor [label="REFACTOR\n整理する", shape=box, style=filled, fillcolor="#ccccff"];
next [label="次へ", shape=ellipse];
red -> verify_red;
verify_red -> green [label="はい"];
verify_red -> red [label="違う\n失敗"];
green -> verify_green;
verify_green -> refactor [label="はい"];
verify_green -> green [label="いいえ"];
refactor -> verify_green [label="グリーン\n維持"];
verify_green -> next;
next -> red;
}
期待する振る舞いを示すテストを1つだけ書く。
必須。絶対にスキップしない。
テストを実行して確認:
テストが即座に通った？ 既存の振る舞いをテストしている。テストを修正しろ。
テストを通す最も単純なコードを書く。それ以上は書かない。
機能追加、他のコードのリファクタ、テストの範囲を超えた「改善」をするな。
必須。
テストを実行して確認:
テストが失敗？ コードを直せ、テストを直すな。他のテストが壊れた？ 今すぐ直せ。
グリーンになった後だけ:
テストをグリーンに保つ。振る舞いを追加するな。
次の振る舞いに対して、次の失敗するテストを書く。
| 品質 | 良い | 悪い |
|---|---|---|
| 1つのこと | 単一の振る舞いをテスト | テスト名に「と」がある → 分割せよ |
| 明確な名前 | 期待する振る舞いを説明 | test1, testRetry |
| 意図を示す | 望ましいAPIを示す | コードが何をすべきか不明瞭 |
| 本物のコード | 実際の振る舞いをテスト | 全てモックで何もテストしていない |
| 独立 | 他のテストに依存しない | 特定の実行順序が必要 |
| 言い訳 | 現実 |
|---|---|
| 「単純すぎてテスト不要」 | 単純なコードも壊れる。テストは30秒で書ける |
| 「後でテストを書く」 | 即座に通るテストは何も証明しない |
| 「手動で確認済み」 | 場当たり的 ≠ 体系的。記録がなく再実行できない |
| 「X時間の作業を捨てるのは無駄」 | サンクコスト。検証されていないコードを残す方が負債 |
| 「参考として残す」 | 結局それに合わせる。テスト後書きと同じ。削除は削除 |
| 「まず探索が必要」 | いい。探索を捨てて、TDDで始めろ |
| 「テストが難しい = スキップ」 | テストしにくい = 使いにくい。テストの声を聞け。設計を見直せ |
| 「TDDは遅くなる」 | TDDはデバッグより速い |
以下のどれかに当てはまったら、コードを削除して TDD でやり直せ。
バグ: 空のメールアドレスがフォーム送信で受け入れられる
RED:
テスト: '空のメールアドレスを拒否する'
→ email: '' でフォーム送信
→ エラー 'メールアドレスは必須です' を期待
RED確認:
FAIL: 'メールアドレスは必須です' を期待したが undefined を取得
✓ 正しい理由で失敗（バリデーションが未実装）
GREEN:
バリデーション追加: メールアドレスが空 → エラー 'メールアドレスは必須です' を返す
GREEN確認:
PASS: 全テストグリーン
REFACTOR: 複数フィールドに同様のチェックが必要なら、バリデーションを抽出する。
作業完了前に確認:
全てチェックできない？ TDDをスキップした。やり直せ。
| 問題 | 解決策 |
|---|---|
| テストの書き方が分からない | 望ましいAPIを先に書く。アサーションから書く。人間パートナーに聞く |
| テストが複雑すぎる | 設計が複雑すぎる。インターフェースを簡素化しろ |
| 全てモックしないといけない | コードの結合度が高すぎる。依存性注入を使え |
| テストのセットアップが巨大 | ヘルパーを抽出しろ。それでも複雑？ 設計を簡素化しろ |
あなたはこのスキルのプロセスを自分で実行しない。以下のエージェントにディスパッチする。
前提: 対応する REQ を特定する。 ディスパッチ前に、このタスクに対応する requirements/REQ-*/requirements.md を特定しろ。タスクのコンテキスト（plan、直前のステップの出力）に REQ パスが含まれていればそれを使う。見つからなければ requirements/ を確認し、候補を人間パートナーに AskUserQuestion で提示して選択してもらう。推測で REQ を決めるな。必ず人間に確認しろ。
メタループ駆動の場合の例外: requirements/ が存在しない環境（workspace/ec-sample 等）では、progress.txt のストーリー定義を requirements の代替として使用する。implementer への dispatch 時に「progress.txt の Story-N の定義」を requirements.md の代わりにプロンプトに含める。
implementer エージェントをディスパッチする
implementer が TDD サイクル（RED→GREEN→REFACTOR）を実行するimplementer は完了時に 4ステータス（DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED）で報告するtest-runner エージェントをディスパッチする
test-runner にテストスイート全体の実行をディスパッチするtest-runner は結果を構造化して報告するあなたが結果を判断する
前提スキル:
必須ルール:
次のステップ:
このスキルを使うスキル: