クイックサマリー: mattpocock氏が公開する「tdd」スキルは、Claude CodeなどのコーディングエージェントにRed-Green-Refactor（レッド・グリーン・リファクタ）のテスト駆動開発サイクルを守らせるためのオープンソーススキルです。npx skills@latest add mattpocock/skills の1コマンドで導入でき、Claude Code・Codex CLIをはじめ複数のコーディングエージェントに対応しています。ライセンスはMITです。
AIが書く「動かないコード」と「意味のないテスト」という課題
コーディングエージェントを日常的に使っている開発者なら、「実装は速いのにテストが形骸化している」という経験があるのではないでしょうか。AIに任せると、実装の内部構造に密結合したテストを大量に生成したり、テストを通すためだけのハードコードを埋め込んだりすることがあります。結果として、テストは緑なのに本番で壊れる——という本末転倒な状態に陥りがちです。
この課題に対する解決策の1つが、TypeScript教育者として知られるmattpocock氏の「Skills For Real Engineers」リポジトリに含まれる tddスキルです。GitHubリポジトリは16.6万スター・1.4万フォークを集めており（2026年7月時点）、tddスキル単体でも配布統計で約41万インストールに達している人気スキルです。
- tddスキルが何をどう「強制」するのか、その仕組み
- Claude Code / Codex CLIへの正確なインストール手順
- 実際の開発フロー（バグ修正・新機能実装）への組み込み方
- 43.1万インストールの improve-codebase-architecture との併用パターン
tddスキルで何ができるか（機能詳細）
公式READMEによると、このリポジトリは「real engineering – not vibe coding（本物のエンジニアリングのための、バイブコーディングではないスキル群）」を掲げており、tddスキルはその中核の1つです。作者自身は公開時に「導入前は実装に密結合した大量の質の低いテストが生成されていたが、導入後は実際の振る舞いを検証する必要最小限のテストだけになった」と説明しています。
主な機能は以下の通りです。
- Red-Green-Refactorサイクルの徹底: まず失敗するテストを書き（Red）、それを通す最小実装を行い（Green）、その後リファクタリングする（Refactor）という順序をエージェントに守らせます
- 良いテスト・悪いテストの判断基準を注入: 実装詳細ではなく振る舞いを検証するテストを書くよう、具体的なガイダンスがスキル内に記述されています
- 小さく確実なステップ: READMEは『達人プログラマー』の「フィードバックの速度があなたの速度制限だ」という言葉を引用しており、大きなタスクを一気に実装させない設計思想が貫かれています
- モデル非依存: 特定モデル専用のプロンプトハックではなく、どのモデルでも機能する汎用的な記述になっています
対応CLI: インストーラーの skills.sh 経由でClaude Code・Codex CLIなど複数のコーディングエージェントに一括導入できます。Claude Code単体では公式プラグイン形式でのインストールにも対応しています。ライセンスはMITで、完全なオープンソースです。
インストール・有効化手順（Claude Code向け）
公式READMEの「Quickstart (30-second setup)」に従うと、導入はインストーラーの実行から始まります。
npx skills@latest add mattpocock/skills実行すると対話形式で「どのスキルを入れるか」「どのコーディングエージェント（Claude Code / Codex CLI等）に入れるか」を選択できます。tddスキルにチェックを入れ、あわせて /setup-matt-pocock-skills も選択しておくのが公式推奨の流れです。
Claude Codeにプラグインとして個別導入したい場合は、リポジトリの .claude-plugin/marketplace.json を利用した以下の方法も使えます。
/plugin marketplace add mattpocock/skills
/plugin install tdd@skills-by-mattpocock導入後、エージェント内で初期設定コマンドを実行します。
/setup-matt-pocock-skills公式ドキュメントによると、このコマンドはイシュートラッカーの選択（GitHub / Linear / ローカルファイル）、トリアージ用ラベル、ドキュメント保存先の3点を質問形式で設定してくれます。設定が終われば準備完了です。動作確認としては、簡単な機能追加を依頼して「先に失敗するテストを書き始めるか」を観察するのが確実と考えられます。
設定例とカスタマイズ
tddスキルは「モデル起動型（model-invoked）」スキルに分類されており、ユーザーが明示的に呼ぶだけでなく、タスクがテストに関わる場面でエージェントが自動的に参照します。リポジトリの設計思想として「小さく・改変しやすく・組み合わせ可能」が掲げられているため、スキルファイル（SKILL.md）を直接編集して自分のプロジェクトのテスト規約に合わせることが公式に推奨されています。
たとえばClaude Codeでは、プロジェクトの CLAUDE.md に以下のような一文を加えることで、tddスキルとの連携を強化できます。
# CLAUDE.md への追記例
- コードの変更時は tdd スキルに従い、必ず失敗するテストを先に書くこと
- テストコマンド: npm run test（vitest）デフォルトのままでも機能しますが、テストランナーのコマンドをCLAUDE.mdに明記しておくと、Red-Greenの確認ループが安定します。
実開発フローへの組み込み方（バグ修正・機能実装での使い方）
tddスキルを実際の開発タスクでどう使うかを、2つのシナリオで示します。
シナリオ1: バグ修正。バグ報告を受けたら、まずエージェントに「このバグを再現する失敗テストを書いて」と依頼します。tddスキル導入下では、エージェントは修正コードを書く前に再現テストの作成に向かいます。テストが赤くなることを確認してから修正に入るため、「直したつもりで直っていない」パターンを構造的に防げます。同リポジトリの /diagnosing-bugs スキルと組み合わせると、原因調査→再現テスト→修正のループが一貫します。
シナリオ2: 新機能実装と設計改善の併用。作者はREADMEで「エージェントはコーディングを高速化する分、ソフトウェアのエントロピー（複雑化）も加速させる」と指摘しています。そこで推奨されているのが、43.1万インストールの improve-codebase-architecture スキルとの併用です。tddで日々の変更に安全網を張りつつ、数日に1回 /improve-codebase-architecture を実行してコードベースの「深いモジュール化」の機会をHTMLレポートで確認する運用が、公式に推奨されています。テストが揃っているほどリファクタリングが安全になるため、この2つは相性が良い組み合わせです。
業種別のユースケースとしては、(1) SaaS開発チームがPR前の品質ゲートとしてtddスキル＋CIを組み合わせる、(2) 受託開発のフリーランスが納品物の品質証明としてテストファーストの履歴を残す、(3) レガシーコード保守の担当者が改修前に振る舞いを固定するテストを書かせる、といった活用が考えられます。
類似スキル・代替手段との比較
| ツール名 | 対応CLI | ライセンス | 最終更新 | 特徴 |
|---|---|---|---|---|
| tdd（mattpocock/skills） | Claude Code / Codex CLI 他 | MIT | 活発（2026年も更新継続） | Red-Green-Refactor強制＋良いテストの判断基準を注入。約41万インストール |
| superpowers（test-driven-development） | Claude Code | OSS | 活発 | 大規模スキル集の一部としてTDDワークフローを提供。単体導入よりセット導入向き |
| CLAUDE.mdへの自前指示 | Claude Code | — | — | 導入コスト最小だが、良いテストの基準まで書き切るのは手間。長期セッションで指示が薄れやすい |
自前のCLAUDE.md指示だけでもTDDを促すことは可能ですが、Qiitaの検証記事では「Claude CodeでTDDは可能かという問いへの答えは条件付きで可能であり、その条件をどこまで明確にできるかが開発者側に懸かっている」と指摘されています。tddスキルはまさにその「条件の明文化」を数十年のエンジニアリング経験に基づいてパッケージ化したもの、と位置づけられます。
注意点・制約・セキュリティ
- 外部通信・データ送信はスキル自体には無し: スキルの実体はMarkdownの指示書であり、スキル自身が外部サーバーへコードを送信することはありません。コードの送信先は利用するエージェント（Claude Code等）のポリシーに従います
- 強制力は絶対ではない: スキルはプロンプトによる誘導であり、フックのような決定論的な強制ではありません。長いセッションではエージェントがサイクルを省略することがあり、その際は明示的に「/tdd」と呼び直す運用が必要です
- テスト基盤が無いプロジェクトでは効果が薄い: テストランナーの実行環境が整っていないリポジトリでは、Red-Greenの確認ループ自体が回りません。先にvitestやpytest等の最低限のセットアップが必要です
- 開発速度は一時的に低下する場合がある: テストファーストは1ステップあたりの所要時間を増やします。使い捨てのプロトタイプには過剰と考えられます
- UI・ドキュメントは英語: スキル本文は英語ですが、日本語での対話にも問題なく機能します
Redditのr/ClaudeAIでは「TDD with Claude Code is a Game Changer!!」というスレッドが234票を集め、多くの肯定的な報告が寄せられている一方、「継続的にTDDを実践できている人は実際どれだけいるのか」という運用定着の難しさを問う投稿も見られます。導入して終わりではなく、CLAUDE.mdやCIとの組み合わせで運用に定着させることが成功の鍵と考えられます。
まとめ — こんな人におすすめ
- tddスキルはRed-Green-Refactorの明文化された規律をClaude Code等に注入するMITライセンスのOSSスキルで、導入は
npx skills@latest add mattpocock/skillsの1コマンドです - 本番運用するコードをAIと書く開発者・保守性を重視するチームにおすすめです。逆に、テスト基盤の無いプロジェクトや使い捨てプロトタイプ中心の人には過剰と考えられます
- improve-codebase-architecture（43.1万インストール）と併用し、「日々のテスト規律＋定期的な設計改善」のセットで運用すると効果を最大化できます
さらに詳しい仕組みやスキル一覧は、mattpocock/skills のGitHubリポジトリとClaude Code公式ドキュメントのスキル・プラグイン解説を参照してください。
コメント