Claude Codeでコーディングする際、「仕様をどう詰めるか」「TDDをどう進めるか」「アーキテクチャの改善計画をどう立てるか」といった開発プロセス上の判断は、毎回プロンプトで指示し直す必要がある。CLAUDE.mdに全部書くとトークンが膨張し、かといって都度入力するのは非効率だ。
mattpocock/skillsは、TypeScript教育で10万フォロワーを持つMatt Pocockが公開するClaude Code向けのスキル集だ。GitHub上で193,000スター超（2026年7月29日時点で193,295）を獲得しており、Claude Code公式マーケットプレイスのプラグインとして、あるいはskills.shのインストーラ経由で導入できる。現在は6カテゴリに41スキルを収録し、開発の上流（詰問による要件固め）から下流（コードレビュー・マージ解消）までをカバーする。
このリポジトリが画期的なのは「開発プロセスそのものをパッケージ化」している点だ。単なるプロンプト集ではなく、参照ファイル・設計思想・ワークフロー全体を含む「知識パッケージ」として配布されている。Claudeに「TDDしろ」と言うだけでなく、TDDの教科書一式を渡す感覚だ。
本記事では現在の41スキルの構成と使い方を日本語で解説する。
mattpocock/skillsはClaude Code向けスキル集——193,000スター超の人気OSS
6カテゴリ・41スキルをプラグインかskills.shの2ルートで導入できる
参照ファイルを同梱した「深い」スキル設計が最大の特徴
エージェント全般の選び方は AIエージェントフレームワーク比較2026｜LangGraph・CrewAI・Dify等9種をStar数・実コードで検証 を起点にすると整理しやすい。
mattpocock/skills のインストール——Claude Codeプラグインとskills.shの2ルート（併用しない）
導入経路は2つあり、READMEは両者を「二つの哲学（two philosophies）」と表現している。 どちらを選ぶかで、更新の届き方とカスタマイズの自由度が変わる。
| ルート | コマンド | 実体 | 更新 | 編集 |
|---|---|---|---|---|
| Claude Codeプラグイン | claude plugins install mattpocock-skills | 管理された読み取り専用バンドル | 作者の更新が自動で届く | 不可（購読する形） |
| skills.sh インストーラ | npx skills@latest add mattpocock/skills | 自分のリポジトリ内の通常ファイル | npx skills update で任意のタイミング | 可（自分のものにできる） |
Claude Code以外のエージェント（Codexなど）を使う場合は、skills.sh側の npx skills@latest add mattpocock/skills が入口になる。
インストーラが「どのスキルを入れるか」「どのコーディングエージェントに入れるか」を対話で聞いてくるため、必要なものだけを選べる。
なおCodexネイティブのプラグインは検討中で、リポジトリ内のADR（.agents/adr/0002-ship-as-a-claude-code-plugin.md）にロードマップとして記載されている。
導入後に必ず走らせる /setup-matt-pocock-skills
ここを飛ばすと後続のスキルが噛み合わない。
READMEはインストール直後の手順として、リポジトリごとに1回 /setup-matt-pocock-skills を実行するよう指示している。
# 1) いずれか一方でスキルを入れる（併用しない）
claude plugins install mattpocock-skills
# もしくは
npx skills@latest add mattpocock/skills
# 2) エージェント内でリポジトリごとに1回だけ実行する
/setup-matt-pocock-skills
このセットアップが対話で確認するのは次の3点だ。
・使用するIssueトラッカー（GitHub / Linear / ローカルファイル）
・トリアージ時に付けるラベル（/triage がこのラベルを使う）
・作成したドキュメントの保存先
setup-matt-pocock-skills 自体を選び忘れないこと。READMEが太字で注意している箇所で、これを外すと初期設定が実行できなくなる。
導入からスキルを呼び出すまでの流れを1枚で示す。
編集したいか？"} Q -- "いいえ（更新を購読したい）" --> P["claude plugins install
mattpocock-skills"] Q -- "はい（自分のものにしたい）" --> N["npx skills@latest add
mattpocock/skills"] P --> S["/setup-matt-pocock-skills
をリポジトリごとに1回"] N --> PICK["対話でスキルを選択
setup-matt-pocock-skills を必ず含める"] PICK --> S S --> CFG["Issueトラッカー / ラベル / 保存先
を決定"] CFG --> USE["user-invoked を打つ or
model-invoked をエージェントが選ぶ"]
プラグイン（購読・自動更新・編集不可）と skills.sh（自分のファイル・手動更新・編集可）の二択
両方入れるとスキルが二重に入るため、必ず片方だけにする
リポジトリごとに
/setup-matt-pocock-skills を1回実行してから他スキルを使う
ライセンスと再配布
リポジトリのライセンスは MIT（LICENSE ファイル）。
スキル定義は実質的にMarkdownの指示書なので、社内向けにフォークして自社の規約を書き足す運用が取りやすい。
skills.sh 経由で入れた場合はファイルが自分のリポジトリに入るため、そのままGitで差分管理できる。
一方プラグイン版は読み取り専用バンドルとして扱われるため、独自改変を前提とするならskills.sh側を選ぶことになる。
mattpocock/skills 41スキルの全体像——6カテゴリ×「誰が呼べるか」の2軸
このリポジトリは初期のフラットな構成から、カテゴリ分割された構成へ再編されている。
2026年7月29日時点で skills/ 配下を数えると、SKILL.md を持つスキルは41個あり、6つのカテゴリに分かれている。
| カテゴリ | スキル数 | 位置づけ |
|---|---|---|
engineering | 17 | コード作業で日常的に使う中核 |
in-progress | 9 | 開発途中。仕様が動く可能性がある |
productivity | 5 | コード以外にも使う汎用ワークフロー |
deprecated | 4 | 非推奨。新規採用は避ける |
misc | 4 | 特定用途のセットアップ系 |
personal | 2 | 作者個人の用途 |
カテゴリ分割と同じくらい重要なのが、READMEが「Reference」節で示すもう1つの軸だ。 スキルは「誰が呼べるか」で二分される。
・user-invoked：利用者が明示的に打ったときだけ起動する。役割は進行の指揮（オーケストレーション）
・model-invoked：利用者が打つことも、タスクに合うとエージェントが自分で選ぶこともできる。役割は再利用可能な規律を保持すること
READMEはこの2軸に1つ制約を課している——user-invokedなスキルはmodel-invokedなスキルを呼べるが、別のuser-invokedスキルは呼べない。 オーケストレーターが多重に入れ子にならないようにする設計だ。
・結局なにができる：41スキルを「日常的に打つ司令塔」と「エージェントが自動で掴む規律」に仕分けて把握できる
・なにを解決する：スキルが増えたときに「どれを自分で打ち、どれを任せるか」が分からなくなる問題
・なにを代替する：スキル名を一覧で暗記する運用を、2軸での仕分けに置き換える
engineering——17スキルの中核
日々のコード作業で使うカテゴリで、user-invoked と model-invoked の両方を含む。
| 呼び出し | スキル | 役割 |
|---|---|---|
| user | ask-matt | 状況に合うスキル・フローを案内するルーター |
| user | grill-with-docs | 詰問セッション＋ドメインモデル構築。CONTEXT.mdとADRをその場で更新 |
| user | triage | Issueをトリアージ役割のステートマシンで進める |
| user | improve-codebase-architecture | 深掘り候補を走査しHTMLレポートで提示、選んだ箇所を詰める |
| user | to-spec / to-tickets | 会話を仕様へ／仕様をブロック関係付きチケット群へ分解 |
| user | implement | 仕様・チケットを実装。要所で/tddを駆動し/code-reviewで締める |
| user | wayfinder | 1セッションに収まらない巨大作業を調査チケットの地図として計画 |
| model | tdd | Red-Green-Refactorを縦切りで回す |
| model | diagnosing-bugs | 再現→最小化→仮説→計測→修正→回帰テストの診断ループ |
| model | code-review | Standards軸とSpec軸を別サブエージェントで並列レビュー |
| model | codebase-design / domain-modeling | Deep Module設計の語彙／ドメインモデルの継続的な研磨 |
| model | resolving-merge-conflicts | コンフリクトをhunk単位で意図に遡って解消（--abortしない） |
| model | prototype / research | 使い捨て試作で設計判断を出す／一次ソース調査を引用付きで記録 |
caveman と write-a-prd（および prd-to-plan / prd-to-issues）は現在のツリーに無い。diagnose は diagnosing-bugs へ改称された。ubiquitous-language・request-refactor-plan・qa・design-an-interface の4つは skills/deprecated/ に移されている。古い記事やSNSの投稿を見てコマンド名をそのまま打つと外れるため、導入時は必ず現在のツリーを確認してほしい。
productivity——コード以外にも効く5スキル
grill-me（計画・設計を容赦なく詰問される）、handoff（会話を引き継ぎ文書に圧縮）、teach（複数セッションでの学習）、writing-great-skills（スキルの書き方リファレンス）、そして model-invoked の grilling（grill-meとgrill-with-docsの背後にある再利用ループ）で構成される。
READMEは grill-me と grill-with-docs を「最も人気のあるスキル」と明言している。
変更を加えたいときは毎回使うことが推奨されており、このリポジトリの入口として位置づけられている。
最初の1回をどう回すか——grill-with-docs から始める
インストールが済んだら、READMEが「最も人気」とする詰問系から入るのが早い。
/grill-with-docs は単に質問を投げるだけでなく、次の3つを同時に進める。
・認識合わせ：作ろうとしている変更について、決定木の全分岐が埋まるまで質問される
・共有語の獲得：プロジェクト固有の用語を洗い出し、CONTEXT.md に蓄積する
・決定の記録：説明しにくい判断をADRとして残す
2回目以降が効いてくる設計だ。
CONTEXT.md に共有語が溜まるほど、エージェントに毎回背景を説明する手間が減り、変数名やファイル名も一貫していく。
READMEはこの効果を「セッションを重ねるほど効いてくる（This concision pays off session after session）」と表現している。
逆に言えば、初回だけ試して「ただ質問が多いスキル」と判断すると本来の価値を取り逃す。 評価するなら、同じリポジトリで数回は回してから判断したい。
「スキルはフォルダ」という構造は変わっていない
再編後も、各スキルが SKILL.md を中心にしたフォルダである点は同じだ。
skills/engineering/tdd/
└── SKILL.md # メインの指示書（Red-Green-Refactorの手順）
SKILL.md がメインの指示書で、補助ファイルはエージェントが必要になったときだけ読み込む。
この「プログレッシブ・ディスクロージャー」方式により、必要なコンテキストだけをロードしてトークン消費を抑える。
設計思想そのもの——なぜこの4つの失敗モードに賭けたのか、Codex系スキル集とどう相互運用するのか——は mattpocock skillsを再評価｜『Skills For Real Engineers』設計思想を読む で別途扱っている。本記事は「何が入っていて、どう入れて、どう呼ぶか」に絞る。
既存のスキルシステムとの比較——何が違うのか
Claude Codeのスキルは.claude/skills/にSKILL.mdを置くだけで動作する。では、mattpocock/skillsの価値は何か。自作スキルやAnthropics公式スキルとの違いを整理する。
| 比較項目 | 自作スキル | mattpocock/skills | Anthropics公式スキル |
|---|---|---|---|
| インストール | 手動でSKILL.md作成 | npx skills@latest addで1コマンド |
手動コピーまたはnpx |
| スキル数 | 必要なだけ | 41スキル（6カテゴリ） | 数スキル |
| 参照ファイル | 自分で用意 | 同梱済み（tests.md等） | 最小限 |
| 設計思想 | 自由 | Deep Module・Vertical Slice重視 | 汎用 |
| カスタマイズ | 完全に自由 | SKILL.mdを編集可能 | SKILL.mdを編集可能 |
| 更新頻度 | 自分次第 | Matt Pocockが継続更新 | Anthropicが管理 |
最大の差別化ポイントは参照ファイルの充実度だ。tddスキルにはtests.md（テストの書き方）、mocking.md（モッキングのルール）、interface-design.md（インターフェース設計）、deep-modules.md（Deep Moduleパターン）、refactoring.md（リファクタリング手法）が同梱されている。単に「TDDしろ」と指示するのではなく、Claudeに読ませる教科書がセットになっている。
ForgeCodeのようなAIコーディングツールが「コード生成」にフォーカスするのに対し、mattpocock/skillsは「開発プロセスの質」を高めるアプローチだ。両者は競合ではなく補完関係にある。
SKILL.mdの構造を覗く
自作する際の参考として、mattpocock/skillsのSKILL.md構造を見ておこう。
---
name: tdd
description: Use this skill when the user asks for TDD, test-driven development, or when writing new features that need tests.
---
## TDD Rules
Red-Green-Refactorのサイクルを回す。1スライスずつ垂直に。
詳細は以下の参照ファイルを順に読むこと:
- `tests.md` — テストの書き方
- `mocking.md` — モッキングのルール
- `refactoring.md` — リファクタリング手法
- `interface-design.md` — インターフェース設計
- `deep-modules.md` — Deep Moduleパターン
descriptionにトリガーワード（TDD, test-driven, writing new features）を明示することで、Claudeの自動呼び出し精度が上がる。本文は「参照ファイルを読め」と指示するだけのシンプルな構造で、具体論は各ファイルに切り出す。
mattpocock/skillsの差別化ポイントは参照ファイルの充実度
SKILL.md本体はシンプル——具体論は参照ファイルに切り出してプログレッシブに読ませる
ForgeCode等の「コード生成ツール」とは補完関係、競合ではない
実践的な導入パターン——どのスキルから始めるか
41スキルを全部入れる必要はない。
skills.sh のインストーラは対話でスキルを選ばせるため、状況に応じて必要なものだけを取ればいい（setup-matt-pocock-skills だけは必ず含める）。
| 状況 | 推奨スキル | 得られる効果 |
|---|---|---|
| 新規プロジェクト | grill-with-docs → to-spec → to-tickets → implement |
詰問で要件を固め、仕様→チケット→実装まで一直線に流す |
| レガシー改善 | improve-codebase-architecture + triage |
深掘り候補をレポート化し、Issueをトリアージで捌く |
| 品質ゲート | tdd + code-review + setup-pre-commit |
Red-Green-Refactorと二軸レビュー、コミット前の安全網 |
| 難しいバグ | diagnosing-bugs |
再現→最小化→仮説→計測→修正→回帰テストを型で回す |
| 巨大な調査 | wayfinder |
1セッションに収まらない作業を調査チケットの地図に落とす |
| スキル自作 | writing-great-skills |
スキルを書くための語彙と原則を参照する |
まず入れるなら grill-with-docs と tdd の2つでいい。
READMEは詰問系（grill-me / grill-with-docs）を「最も人気のあるスキル」とし、変更を加えるたびに毎回使うよう勧めている。
詰問で認識を揃えてからTDDで1つずつ実装する——この2段だけでも、エージェントの手戻りは目に見えて減る。
カスタマイズも自由
インストール後のSKILL.mdは自由に編集してよい。チーム固有のコード規約やデプロイ手順を追記すれば、「mattpocock/skillsをベースにした自社スキル」になる。
# インストール後にチーム規約を追記
vi .claude/skills/tdd/SKILL.md
# 追記例:
# - テストはJestではなくVitestを使う
# - カバレッジ80%以上を維持する
# - E2EテストはPlaywrightで書く
.claude/skills/をGit管理に含めるとチーム全員で同じスキルセットを共有できる。~/.claude/skills/（Personalスコープ）に置くと個人設定として運用可能。プロジェクト固有のカスタマイズはProjectスコープ、汎用的なものはPersonalスコープに置き分けるのが基本だ。
自分独自のスキルを作りたい場合は、リポジトリ同梱の writing-great-skills が語彙と原則のリファレンスになる。スキルでワークフローを定義し、足りないツール連携はMCPサーバー側で補う——この役割分担を意識すると、どちらに何を書くかで迷わなくなる。
新規/レガシー/チーム/ドキュメント——状況別に必要スキルを選べる
tdd + write-a-prdの組み合わせが汎用性最高
SKILL.mdはインストール後に自由にカスタマイズ可能でチーム資産化できる
📌 まとめ
mattpocock/skillsは、Claude Code向けの開発プロセススキル集として現在最も充実したOSSリポジトリのひとつだ。npx skills@latest addコマンド1行でPlanning・Development・Tooling・Writingの4カテゴリ・18スキルを個別導入でき、参照ファイルを同梱した「深い」スキル設計によってClaudeの実行品質を底上げする。
最大の価値は「開発プロセスの教科書をClaudeに渡せること」だ。TDDスキルにはtests.md・mocking.md・refactoring.md・deep-modules.mdが同梱されており、単なる「TDDしろ」という指示を超えた体系的な教育がエージェントに施せる。Vertical SliceやDeep Moduleといった設計哲学が、スキルを通じてコードベースに浸透していく。
導入の最短コースはtdd + write-a-prdの2スキルだ。PRDで要件を固めてTDDで1スライスずつ実装するという王道サイクルを、Claude Codeが自律的に回せるようになる。慣れたらgrill-meで設計レビューを厳しくし、improve-codebase-architectureで既存コードをDeep化していく。18スキル全部ではなく、プロジェクトに必要なものだけを選んで育てるのが正解だ。
Claude Codeのスキル機構そのもの（SKILL.md のfrontmatterや読み込みの仕組み）を押さえたうえで導入すれば、自社独自のスキル開発にもスムーズに移行できる。
関連記事: mattpocock skillsを再評価｜『Skills For Real Engineers』設計思想を読む
