Claude Codeでmattpocock skillsを使う — 導入とスキルの使い分け
mattpocock/skillsは、聞き取り・仕様化・TDD・レビューをスキルで配るプラグインです。導入コマンド、ユーザー起動型とモデル起動型の違い、症状別の使い分けをまとめます。
mattpocock/skillsは、開発者のMatt Pocock氏が日々の開発で使うエージェント用スキルを、プラグインとして配っているリポジトリです。Claude Codeには1行のコマンドで入ります。導入後は /grill-me で計画を問い詰めさせたり、/tdd でテスト駆動開発を回したりできます。
この記事では、導入コマンドと初回設定、スキルの2つの起動方式、困りごと別の使い分けを扱います。第三者製のプラグインなので、導入前にスコープと重複導入の注意を確かめておくと安全です。
mattpocock/skillsとは何か
mattpocock/skillsは、小さく組み合わせられるスキルを集めたGitHubリポジトリです。READMEは「vibe codingではなく本物のエンジニアリングのためのスキル」と位置づけ、GSDやBMAD、Spec-Kitのように開発の進め方そのものを握る方式とは距離を置いています。小さく、手元で書き換えやすく、モデルを選ばない作りです。
Claude Codeのマーケットプレイスにも Matt Pocock's Skills として載っています。作者はMatt Pocock氏です。ライセンスはMITです。
スキルが対象にする失敗は4つあります。
スキルが狙う4つの失敗
エージェントが意図を外す
聞き取りの不足が原因です。
/grill-meと/grill-with-docsで、作り始める前に質問攻めにします。エージェントが冗長すぎる
プロジェクトの用語が共有されていないのが原因です。
/grill-with-docsが用語集とADR(設計判断の記録)を育てます。コードが動かない
フィードバックの輪がないのが原因です。
/tddと/diagnosing-bugsで、赤・緑・リファクタとデバッグ手順を固定します。泥団子になる
設計に投資していないのが原因です。
/to-specと/improve-codebase-architectureで設計の観点を持ち込みます。
Claude Codeへの導入と初回設定
Claude Code向けのインストールコマンドは1行です。
claude plugin install mattpocock-skills@claude-plugins-officialプラグインは既定で自動更新されます。セッション中に入れたい場合は、同じ名前を /plugin install mattpocock-skills@claude-plugins-official に渡します。この形はパネルが開くだけで、スコープを選んで確定します。
スコープの選び方は、プラグイン文書に3つあります。
| スコープ | 有効になる範囲 | 設定の置き場所 |
|---|---|---|
| ユーザー | 有効になる範囲自分の全プロジェクト | 設定の置き場所~/.claude/settings.json |
| プロジェクト | 有効になる範囲そのリポジトリの全員 | 設定の置き場所.claude/settings.json |
| ローカル | 有効になる範囲自分とそのリポジトリだけ | 設定の置き場所.claude/settings.local.json |
プロジェクトスコープでは、設定をコミットしても共同作業者の手元にはダウンロードされません。各自が claude plugin install <name>@<marketplace> --scope project を一度実行します。
入れたら、スキルが見えるかを確かめます。プロンプトで / を打つと、プラグインのスキルは /<プラグイン名>:<スキル名> の形で並びます。シェルでは次の2つで確認できます。
claude plugin list
claude plugin details mattpocock-skillsdetails の Always-on 行は、プラグインが毎セッションに足すトークン数です。どのスキルが重いかも行ごとに出ます。
リポジトリごとに1回だけ /setup-matt-pocock-skills
エンジニアリング系のスキルを使う前に、リポジトリで一度だけセットアップを実行します。
/setup-matt-pocock-skills聞かれることは3つです。
- 使う課題管理の仕組み(GitHub、GitLab、ローカルファイル、その他)
- トリアージ時に付けるラベル(
/triageが使う) - 作成するドキュメントの保存先
/to-spec や /to-tickets が成果物を公開する先は、この答えで決まります。先にここを通しておかないと、チケットの出力先が定まりません。
重複して入れない
READMEは、プラグインとskills.shの2つの導入方法を並べています。プラグインは自動更新で、skills.shは編集できるファイルをプロジェクトにコピーして手で更新します。同じエージェントにどちらも入れると、すべてのスキルが二重になります。1つのエージェントにつき片方だけ選びます。プラグイン経由で入っているかは claude plugin list で確かめられます。skills.shで入れたスキルは、プロジェクト内にファイルとして残ります。
ユーザー起動型とモデル起動型
スキルは「誰が呼べるか」の1軸で分かれます。
| 種類 | 呼び方 | 役割 |
|---|---|---|
| ユーザー起動型 | 呼び方自分が /名前 で打ったときだけ | 役割流れを組み立てる(オーケストレーション) |
| モデル起動型 | 呼び方自分でも、作業に合えばエージェントが自動でも | 役割繰り返し使う規律を持つ |
ユーザー起動型は、別のユーザー起動型を呼べません。モデル起動型は呼べます。たとえば /grill-me は、モデル起動型の grilling(質問を重ねる手順の部品)を使います。
この区別は、Claude Codeのスキル文書の disable-model-invocation: true と同じ考え方です。文書では、デプロイやコミットのように実行タイミングを自分で握りたい作業に付ける設定として説明されています。
困りごと別の使い分け
何を作るか決まっていないとき
/grill-me は、計画や設計について、設計の枝がすべて決まるまで質問し続けます。コードに限らない用途です。作者が最も人気と呼ぶスキルで、変更のたびに使う前提です。
用語集も育てたいときは /grill-with-docs です。聞き取りに加えて、用語の定義を詰め、用語集のGLOSSARY.mdとADRを書き足します。
仕様とチケットにするとき
/to-spec: 今の会話を仕様にして、課題管理に公開する。聞き取りはせず、すでに話した内容をまとめる/to-tickets: 計画や仕様を、追跡弾(tracer bullet)型のチケットに割る。各チケットは依存関係を宣言する
仕様のために、先に /grill-me で詰めておくのが想定された順番です。/to-spec は、触るモジュールについて質問してから仕様を作ります。
実装するとき
/implement は、仕様やチケットの内容を作ります。事前に決めた境目で /tdd を回し、コミット前に /code-review で締めます。仕様全体を1つの統合ブランチで進める /implement-spec もあります。サブエージェントを依存関係の空いたチケットへ並列に走らせる構成です。
/tdd は単体でも使えます。1つの縦の切り口ずつ、失敗するテストから書かせる流れです。Claude Code単体でのTDDの組み方は、Claude Codeでテスト駆動開発を回す手順にまとめています。
バグを追うとき
/diagnosing-bugs は、難しいバグや性能劣化向けです。まず「そのバグで赤くなる」フィードバックの輪を作り、最小化、仮説、計測、修正、回帰テストの順に進めます。段階ごとに関門を置いた手順です。
大きすぎる仕事と、あとの整理
/wayfinder: 1セッションでは抱えきれない仕事を、判断チケットの地図にして1つずつ解決する/improve-codebase-architecture: コードベースを調べて、設計を深くできる候補を示す。作者は数日おきの実行を勧めるが、古いコードベースの泥を解いてくれるわけではないと断っている/handoff: 会話を引き継ぎ文書に圧縮し、別のエージェントが続けられるようにする/retro: セッション後に、エージェントの環境(ナビゲーション、自動チェック、規約)の改善案を重い順に出す
どれを使えばよいか迷ったら、ユーザー起動型の ask-matt が案内役です。状況を伝えると、どのスキルや流れが合うかを答えます。
仕様から実装までを1本通す流れ
スキルをつなぐと、小さな機能なら次の順になります。
新機能を通すときの順序
- 1
聞き取る
/grill-meか/grill-with-docsで、要件の枝を潰す。 - 2
仕様にする
/to-specが会話を仕様にして課題管理に公開する。 - 3
チケットに割る
/to-ticketsが依存関係つきのチケットに分ける。 - 4
実装する
/implementが/tddを回して作る。 - 5
レビューする
/code-reviewが標準への適合と仕様への適合を、別々のサブエージェントで確かめる。
/code-review の2軸は「規約に従っているか(Fowlerのコードの臭い基準を含む)」と「元の課題や仕様どおりか」です。別々のサブエージェントで走るため、片方の観点がもう片方を濁しません。
入れる前に確認したいこと
数が合わない
マーケットプレイスの掲載ページは「21個のスキルの集まり」と説明しています。READMEのリファレンスには、ユーザー起動型とモデル起動型を合わせて27個が載っています。どちらの数が実態かは、入れてみないと分かりません。入れたあとに、/ の候補と claude plugin details で実際の一覧を見てください。
コンテキストの消費
スキルは数が多いほど、毎セッションに載る説明文も増えます。Always-on の数値が気になる場合は、claude plugin detailsでプラグインのコンテキスト消費を測る方法で、重いスキルを特定できます。不要なら claude plugin disable で止められます。
同系統のプラグインとの併用
計画・TDD・レビューを配るプラグインには、superpowersもあります。両方入れると、TDDやデバッグ、レビューの役割が重なります。違いはClaude Codeでsuperpowersを使う手順で確かめられます。まず片方だけで一通り回してから、足りない場面で足す進め方が混乱を避けます。
スキルそのものの仕組み
プラグインのスキルは、SKILL.mdを置いたフォルダの集まりです。自作との違いや発火条件は、Claude Codeのスキルの仕組みの解説にあります。気に入らない部分は書き換えて自分用にして構いません。書き換えを前提にするなら、編集できるファイルが手元に残るskills.sh経由が向きます。
まとめ
mattpocock/skillsの核は、作る前の聞き取り(/grill-me)と、動かすための輪(/tdd、/diagnosing-bugs)です。まず claude plugin install で入れ、リポジトリで /setup-matt-pocock-skills を一度通します。/grill-me と /tdd の2つから試し、作業が数日にまたがる場面で仕様化とチケット化を足す進め方なら、スキルの数に振り回されません。