Total TypeScript で有名な Matt Pocock さんが、自身の .claude ディレクトリから切り出したスキル集 mattpocock/skills を公開しています。

/grill-me（実装前に AI が人間を「尋問」して計画を固めるスキル）が X でバズったのをきっかけに、リポジトリは 2026年2月の公開から5ヶ月で 157K star / 13.5K fork（2026-07-05 時点）まで伸びています。

自分もこのリポジトリのスキルを一式導入したので、全体像・設計思想・主要スキルを整理します。

なお、この記事は skills をすでに使っている人向けです。skills の仕組み自体（SKILL.md の書き方や配置場所）には触れません。

リポジトリの全体像

38 個のスキルが 6 つのバケットに整理されています。

バケット	数	中身
engineering	16	コード作業で毎日使うもの（tdd, code-review, to-prd など）
productivity	5	コード以外にも使える汎用系（grill-me, handoff, teach など）
misc	4	セットアップ系ユーティリティ（pre-commit 設定、git ガードレールなど）
personal	2	Mattさんの個人用（Obsidian 連携、記事編集）
in-progress	7	開発中。「壊れる前提」と明言されている（wayfinder など）
deprecated	4	廃止済み。ただし削除せず残されている

安定バケットは上の 4 つで計 27 スキル。in-progress と deprecated が別枠として public に残っているのが特徴で、スキルがどう進化・淘汰されてきたかを追えます。たとえば deprecated には用語集抽出の ubiquitous-language が眠っていますが、その役割は現在 engineering の domain-modeling がカバーしており、設計の変遷が読み取れます。

設計思想: 小さく、組み合わせ可能に

README の冒頭にこのリポジトリの立ち位置が書かれています。GSD・BMAD・Spec-Kit のような「開発プロセスごと面倒を見る」アプローチはプロセスの中で問題が起きたときに直しにくい、それに対してこのスキル群は小さく・改造しやすく・組み合わせ可能に作る、という思想です。

構造面で面白いのは、全スキルが user-invoked / model-invoked の 2 種類に分類されていることです。

user-invoked: 人間が /grill-me のように明示的に呼ぶもの。役割はオーケストレーション
model-invoked: タスクに合えばエージェントが自発的に使ってよいもの。再利用可能な「規律」を保持する

そして「user-invoked スキルは model-invoked スキルを呼んでよいが、別の user-invoked スキルを呼んではならない」というルールが敷かれています。エントリポイントと部品が明確に分離されているわけです。

たとえばバズった grill-me 本体は、実質これだけです。

---
name: grill-me
description: A relentless interview to sharpen a plan or design.
disable-model-invocation: true
---

Run a `/grilling` session.

尋問ロジックの実体は model-invoked の grilling にあり、grill-me はその入口に過ぎません。後述の grill-with-docs も同じ grilling を呼ぶ別の入口です。この「薄い入口 + 共有部品」のパターンは、自作スキルが増えてきたときの整理法としてそのまま真似できます。

エージェントの4つの失敗モード別に見る主要スキル

README 自体が「AI エージェントの典型的な失敗モード別」に構成されているので、それに沿って主要スキルを紹介します。

失敗モード1: 頼んだものと違うものが出てくる → grill-me / grill-with-docs

最も頻度が高い失敗は意図の齟齬です。The Pragmatic Programmer の「No-one knows exactly what they want」が引かれています。

/grill-me は、実装に入る前に AI が人間を質問攻めにするスキルです。ポイントは 3 つ。

質問は必ず 1 問ずつ。まとめて聞かない
各質問に AI 自身の推奨案を付ける。人間は Yes/No か修正を返すだけでよい
コードベースを読めば分かる質問は、人間に聞かずにコードを読んで潰す

そして「合意に達したと人間が確認するまで実装しない」と明記されています。

/grill-with-docs は同じ尋問に domain-modeling（後述）を組み合わせたもので、尋問の副産物として ADR と用語集がリポジトリに溜まっていきます。コード作業ならこちら、それ以外（文章の構成、企画づくりなど）なら grill-me、という使い分けです。

失敗モード2: エージェントの説明が冗長 → domain-modeling

プロジェクト固有の概念に名前が付いていないと、エージェントは 1 語で済むことを 20 語で説明し始めます。これに対する処方箋が共有言語で、domain-modeling スキルが担当します。

このスキルは用語集 CONTEXT.md と ADR を管理します。README に載っているMattさん自身のリポジトリの例が分かりやすいです。

Before: 「コースのセクション内のレッスンが『実体化』される（ファイルシステム上の場所を与えられる）ときに問題がある」
After: 「materialization cascade に問題がある」

一度 CONTEXT.md に定義された用語は、変数名・ファイル名・会話のすべてで一貫して使われるようになり、コードベースのナビゲーションも楽になります。

ADR については「不可逆・文脈なしでは不可解・真のトレードオフの結果」の 3 条件がすべて揃ったときだけ書く、と絞り込まれているのも実用的です。何でも ADR にすると読まれなくなる、という経験則が透けて見えます。

失敗モード3: コードが動かない → tdd / diagnosing-bugs

意図が合っていても出力がダメなら、フィードバックループを疑え、という章です。

/tdd は red-green-refactor のループを回すスキルですが、独自色が強いのは seam（縫い目） の扱いです。テストを書く境界（公開インターフェース）を実装前に人間と合意し、合意していない seam にはテストを書かない、というルールになっています。テスト工数を重要経路に集中させるための仕組みです。ほかにも「tautological test（実装と同じ計算で期待値を作ってしまい、絶対に落ちないテスト）」などのアンチパターン集が同梱されていて、テスト方針のドキュメントとして単体でも読む価値があります。

/diagnosing-bugs は難しいバグ向けの診断ループで、reproduce → minimise → hypothesise → instrument → fix → regression-test という手順を強制します。「とりあえず修正してみる」への抑止力です。

失敗モード4: 泥団子ができあがる → codebase-design / improve-codebase-architecture

エージェントはコーディングを加速するぶん、ソフトウェアのエントロピー増大も加速する、という問題意識です。

codebase-design は A Philosophy of Software Design の deep module（小さなインターフェースの裏に多くの機能を隠す）の語彙を各スキルに供給する部品で、improve-codebase-architecture はコードベースをスキャンして「深化させられる箇所」を HTML レポートで提示し、選んだものを尋問形式で詰めていく user-invoked スキルです。Mattさんは数日に一度これを回すことを推奨しています。

計画から実装まで: フルワークフロー

個々のスキルとは別に、計画〜実装を一気通貫でつなぐ流れが用意されています。

/grill-with-docs（計画を尋問で固める）
    ↓
/to-prd（会話をそのまま PRD 化して issue tracker に発行）
    ↓
/to-issues（PRD を vertical slice の issue 群に分割）
    ↓
/implement（issue を tdd で実装し、code-review で締める）

/to-prd はインタビューをしないのがポイントです。尋問は grill-with-docs で済んでいる前提で、会話の内容をただ PRD に合成します（唯一、テストを書く境界 = seam の想定だけは人間に確認を取ります）
/to-issues は tracer bullet 方式で、1 issue = スキーマから UI・テストまで貫通する薄い縦切りにします。単体でデモ可能な粒度です
/implement の中身は数行で、/tdd と /code-review に委譲します。/code-review は Standards（リポジトリのコーディング規約に沿っているか）と Spec（元 issue の要求を満たしているか）の 2 軸を並列のサブエージェントでレビューする構成です

このワークフロー系スキルを使う場合は、リポジトリごとに /setup-matt-pocock-skills を一度実行して issue tracker（GitHub / GitLab / ローカル markdown）と triage ラベルを設定しておく必要があります。

残りのスキル一覧

ここまでで触れなかった安定バケットのスキルです。

スキル	一言説明
ask-matt	「今の状況ならどのスキル？」を答えるルーター
triage	issue を状態機械（要評価→報告者待ち→エージェント可…）で振り分け
prototype	設計判断のための使い捨てプロトタイプ作成（UI は複数案を1ルートで切替）
research	一次情報ベースの調査をバックグラウンドで実行、出典付き markdown に保存
resolving-merge-conflicts	進行中の merge/rebase コンフリクト解消
handoff	会話を引き継ぎドキュメントに圧縮して別エージェントに渡す
teach	カレントディレクトリを教材置き場にした複数セッションの学習支援
writing-great-skills	良いスキルの書き方リファレンス（スキル自作派は必読）
git-guardrails-claude-code	push / reset --hard 等の危険な git 操作を hook でブロック
setup-pre-commit	Husky + lint-staged のセットアップ
migrate-to-shoehorn	テストの `as` 型アサーション置換（Mattさんのライブラリ向け）
scaffold-exercises	教材の演習ディレクトリ生成（Mattさんのコース制作用）
edit-article / obsidian-vault	Mattさんの個人用（記事編集・Obsidian 管理）

in-progress の注目スキル: wayfinder

開発中バケットの中で、いまMattさんが最も熱を入れているのが wayfinder です。1 セッションに収まらない大きな仕事を issue tracker 上の「地図」として管理するオーケストレーターで、まだ言語化できていない領域を「戦場の霧（fog of war）」として明示的に残し、調査チケットを 1 セッション 1 枚ずつ解決するたびに霧が晴れて新しいチケットが生まれる、という設計になっています。

Mattさん自身が「grill-me の次の進化系」と位置づけていて、コース制作を丸ごとこれで計画しているそうです。ただし in-progress、つまり破壊的変更が前提のバケットにいるので、この記事では深入りしません。安定バケットに昇格したら改めて書きたいと思っています。

導入方法

skills.sh のインストーラが用意されています。

npx skills@latest add mattpocock/skills

対話式で「どのスキルを」「どのエージェント（Claude Code / Codex / Cursor など）に」入れるかを選べます。

1 点だけ注意があります。前述のとおりスキル間に呼び出し関係があるので、つまみ食いすると依存が切れます。主な依存関係は次のとおりです。

スキル	依存先
grill-me	grilling
grill-with-docs	grilling, domain-modeling
implement	tdd, code-review
improve-codebase-architecture	codebase-design, domain-modeling, grilling
to-prd / to-issues / code-review	setup-matt-pocock-skills が生成する設定ドキュメント

迷ったら「使いたい user-invoked スキル + model-invoked 一式」で入れておくのが安全です。

まとめ

mattpocock/skills は「プロセスを丸ごと渡さず、小さい部品を組み合わせる」思想のスキル集。user-invoked / model-invoked の分離は自作スキルの整理法としても参考になります
入口としては /grill-me 単体がおすすめ。計画がある作業すべてに使えます
気に入ったら /grill-with-docs へ。ADR と用語集が溜まり始めます
issue tracker 運用まで踏み込むなら /setup-matt-pocock-skills + to-prd → to-issues → implement のフルワークフロー
スキルは小さく改造前提で書かれているので、フォークして自分の環境に合わせて使いましょう

リンク