メニュー
レッド・グリーン・リファクタのループによるテスト駆動開発。ユーザーがTDDで機能開発やバグ修正をしたい場合、「レッド・グリーン・リファクタ」に言及した場合、統合テストを求めた場合、またはテストファースト開発を依頼した場合に使用します。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
コード変更・diff・ブランチ・PRについて、リッチでインタラクティブな解説を生成するスキル。「この変更を解説して」「このPRを説明して」「diffを分かりやすくまとめて」「このブランチの変更点を教えて」「変更内容の解説ページを作って」と言われたら使う。背景・直感・コード・批評・クイズの5セクションから成る自己完結HTMLファイルを出力する。解説だけでなく批判的な視点も含む。他人のPRや自分の変更を、初学者にも分かる形で理解・共有したい場面で積極的に使うこと。
長考や自問自答の末に、元の質問から逸れた（drift した）回答をしてしまったときに、 思考を原点に立て直すためのリカバリスキル。同一セッションで元の質問に答え直す「原点回帰」を核に、 それでも直らない場合は、汚染のないセッションで再出発するための「質問カード」を出して /clear や 新セッションへ誘導する、一直線のエスカレーション型。 「迷走してる」「質問に答えてない」「そんなこと聞いてない」「ズレてる」「話が逸れた」「やりなおして」 「元の質問に戻って」「なんでその話になってるの」と言われたら使う。 ユーザーが直前の回答に対して困惑・不満・「？」を示したとき、あるいは自分の回答が元の質問と かみ合っていないと気づいたときは、指示される前にこのスキルを提案・発動してよい。
忖度をやめ、容赦なく正直な高レベルアドバイザーとして振る舞うモード。一度呼ばれたらセッション全体でこの人格を貫く。 ユーザーの思考に意見し、前提を疑い、避けている盲点を暴き、弱い推論を解剖し、自己欺瞞・言い訳・機会費用を名指しする。ただし丁寧な言葉を使い、攻撃と正直さを混同しない。 「厳しく評価して」「容赦なく」「盲点を指摘して」「甘やかさないで」と言われたら使う。対象は仕事・思考・意思決定・計画・戦略。 ユーザーが同意や称賛を求めているだけに見えるとき、自分を正当化して逃げているとき、不快な決断を先送りしているときは、このモードを提案してよい。
今のClaude Codeセッションでの会話を踏まえて、そこで得た学びを「個人用の公開メモ」1枚にまとめてチャットに返すスキル。「/matome 〇〇についてまとめて」「ここまでの会話をまとめて」「今の話を公開メモにして」「会話の内容を1枚にまとめて」と言われたら使う。単発の質問への要約ではなく、会話の中で芋づる式に出てきた話題（〇〇を聞いたら△△が出て、それを掘ったら□□が…）を全部拾い、3ヶ月後の自分が読んで理解できる順に再構成するのが特徴。社内コードや機密は自動で抽象化する。
対象を徹底的に理解する。記事、リポジトリ、本、論文などのコンテンツについて、メンタルモデルの獲得を目指して深い理解に達するまで探索・質問・解説を繰り返す。「徹底的に理解したい」「深掘りしたい」「このリポジトリを理解したい」「この本を読み解きたい」といった場面で使用する。
虫食い思考（コンサル業界の「空パック / Ghost Deck」に相当）でユーザーと一緒に進めるためのスキル。 先に「型」（答えるべき問い・アジェンダ・テンプレ）を作って「虫食い状態」にしてから、 その穴を1つずつ埋めていく進め方。 「虫食いで」「虫食い思考で」「空パックで」「骨子から作って」「先に型を作って」 「アジェンダから決めて」「アウトライン先行で」「skeleton-first」「ghost deck」 と言われたら使う。 Q振り返り、次Q発表準備、提案資料作成、採用面接の準備、ブログや記事の構成、 「何かを書く／考える前段で先に骨組みを置きたい」場面で積極的に使うこと。 ユーザーの思考が発散して整理が必要そうなときに、「先に虫食いで構造化しませんか？」と提案するのもよい。
| name | tdd |
| description | レッド・グリーン・リファクタのループによるテスト駆動開発。ユーザーがTDDで機能開発やバグ修正をしたい場合、「レッド・グリーン・リファクタ」に言及した場合、統合テストを求めた場合、またはテストファースト開発を依頼した場合に使用します。 |
| ref | https://github.com/mattpocock/skills/tree/main/tdd.SKILL.md |
基本原則: テストは実装の詳細ではなく、公開インターフェースを通じて振る舞いを検証すべきです。コードは完全に変わる可能性がありますが、テストは変わるべきではありません。
良いテストは統合テストスタイルです。公開APIを通じて実際のコードパスを実行します。テストはシステムが 何を するかを記述し、どのように するかは記述しません。良いテストは仕様書のように読めます。「ユーザーは有効なカートでチェックアウトできる」と書けば、どんな機能が存在するかが正確にわかります。これらのテストは内部構造を気にしないため、リファクタリングに耐えられます。
悪いテストは実装に結合しています。内部の協調オブジェクトをモックしたり、プライベートメソッドをテストしたり、外部手段（インターフェースを使わずにデータベースを直接クエリするなど）で検証したりします。警告サイン：リファクタリングするとテストが壊れるのに、振る舞いは変わっていない場合です。内部関数の名前を変えてテストが失敗するなら、それらのテストは振る舞いではなく実装をテストしていたのです。
詳しくはtests.mdの例とmocking.mdのモッキングガイドラインを参照してください。
すべてのテストを先に書いてから、すべての実装を書くことはしないでください。 これは「水平スライス」です。REDを「すべてのテストを書く」、GREENを「すべてのコードを書く」として扱っています。
これは質の悪いテストを生み出します：
正しいアプローチ: トレーサーバレットによる垂直スライス。1つのテスト → 1つの実装 → 繰り返し。各テストは前のサイクルから学んだことに応じて書きます。コードを書いたばかりなので、どの振る舞いが重要で、どう検証すべきかを正確に把握しています。
間違い（水平）:
RED: test1, test2, test3, test4, test5
GREEN: impl1, impl2, impl3, impl4, impl5
正しい（垂直）:
RED→GREEN: test1→impl1
RED→GREEN: test2→impl2
RED→GREEN: test3→impl3
...
コードを書く前に：
質問する：「公開インターフェースはどのような形にすべきですか？テストすべき最も重要な振る舞いはどれですか？」
すべてをテストすることはできません。 どの振る舞いが最も重要かをユーザーと正確に確認してください。あらゆるエッジケースではなく、クリティカルパスと複雑なロジックにテストの労力を集中させましょう。
システムについて1つのことを確認する1つのテストを書きます：
RED: 最初の振る舞いのテストを書く → テストが失敗する
GREEN: テストを通す最小限のコードを書く → テストが通る
これがトレーサーバレットです。パスがエンドツーエンドで機能することを証明します。
残りの各振る舞いについて：
RED: 次のテストを書く → 失敗する
GREEN: テストを通す最小限のコード → 通る
ルール：
すべてのテストが通った後、リファクタリング候補を探します：
REDの状態でリファクタリングしないこと。 まずGREENにしてください。
[ ] テストは実装ではなく振る舞いを記述している
[ ] テストは公開インターフェースのみを使用している
[ ] テストは内部リファクタリングに耐えられる
[ ] コードはこのテストに対して最小限である
[ ] 投機的な機能が追加されていない