「Skills for Real Engineers. Straight from my .claude directory.」 — Total TypeScript 著者 Matt Pocock が毎日実際に使っている作業手順をそのまま公開したリポジトリ mattpocock/skills（★2万強・スター急増中）。
この教科書は、29個のスキルを ①思想 → ②一覧 → ③深掘り → ④自分環境への取り込み判断 の順で読み解き、「自分のClaude Codeに取り込むべきか」 を1冊で判断できるようにしたものです。
読み方: 各部はクリックで開閉します（開閉状態は記憶されます）。スマホ対応。Mattの原典 SKILL.md へのリンクを各所に置いています。
Matt Pocock は TypeScript 界隈の著名エンジニア（Total TypeScript 著者・X約12.8万フォロワー）。彼が Claude Code・Codex 等のコーディングエージェントを毎日使う中で、「よくある失敗モード」 を直すために作ったのがこのスキル群です。
| 失敗モード | 問題 | Mattの解決策 |
|---|---|---|
| #1 エージェントが意図を理解しない | 「こんなはずじゃなかった」のズレ | grill-me / grill-with-docs — 作業前に執拗に質問して設計を詰める |
| #2 エージェントが冗長すぎる | 1語で済む所を20語使う・専門用語が噛み合わない | CONTEXT.md（後述）で共有語彙を定義 |
| #3 プロセスに制御を奪われる | GSD・BMAD・Spec-Kit等が「プロセス全体を独占」してバグ修正が困難に | 小さく・適応しやすい・composable な設計（対極の思想） |
「These skills are designed to be small, easy to adapt, and composable. They work with any model. Hack around with them. Make them your own.」
— 小さく・改造しやすく・組み合わせ可能。どのモデルでも動く。ハックして自分のものにせよ。
これは 「プロセスを独占しない」 という強い意思表示です。GSD/BMAD/Spec-Kitが「開発プロセス全体を握る」のに対し、Mattのスキルは個別の小さな道具で、必要な時だけ呼び出し・自由に組み合わせる・自由に書き換えることを前提にしています。
Mattは skills/ 配下をバケットフォルダに分け、どのスキルを公開するかを厳格に管理しています。
| バケット | 意味 | plugin.json/README掲載 |
|---|---|---|
engineering/ | 毎日のコード作業 | ✅ 掲載 |
productivity/ | 毎日の非コード作業 | ✅ 掲載 |
misc/ | 手元に置いているが滅多に使わない | ✅ 掲載 |
personal/ | 自分の環境に依存（外部非推奨） | ❌ 非掲載 |
in-progress/ | 出荷前のドラフト | ❌ 非掲載 |
deprecated/ | もう使わない | ❌ 非掲載 |
ルール: engineering/productivity/misc の各スキルは、トップの README.md と .claude-plugin/plugin.json の両方にエントリを持つ必須。それ以外は両方に出してはいけない。READMEと実体（plugin.json）の乖離を許さない運用です。
失敗モード#2の解決策。プロジェクト固有の専門用語辞書を CONTEXT.md に書き、エージェントが用語を正しく使えるようにする。DDD（ドメイン駆動設計）の「ユビキタス言語」のエージェント版。
Mattの CONTEXT.md では「Issue tracker」「Issue」「Triage role」等の用語を正名・使ってはいけない同義語付きで定義しています。例:
重要な制約: CONTEXT.md は用語辞書であって仕様書ではない。実装詳細を書かない。grill-with-docs 等のスキルが、会話中に用語が確定したらその場でインライン更新します（バッチしない）。
自分環境との比較: この CONTEXT.md は、筆者の SSOT（obsidian-ssot）の「全体マップ_MOC」「用語集」「00_SYSTEM」と同じ思想です。Matt流の「用語の正名とNG同義語を明示」は、筆者のSSOT運用にも取り入れられる示唆。
分類 × 一言目的 × トリガー × 筆者環境の類似スキル。詳細は第3部（核心16個）と第4部（評価表）で。
| スキル | 一言目的 | トリガー | 筆者環境の類似 |
|---|---|---|---|
| zoom-out | コードの上位レイヤーの地図 | 知らない領域・「zoom out」 | Explore エージェント |
| diagnose | バグの規律ある診断ループ | バグ報告・「diagnose this」 | systematic-debugging |
| grill-with-docs | 計画をグリリング+CONTEXT.md更新 | 設計ストレステスト | brainstorming + SSOT |
| improve-codebase-architecture | アーキテクチャの深深化機会を発見 | リファクタ候補探索 | （該当なし・新規） |
| prototype | 使い捨てプロトタイプで設計検証 | 「prototype」「試しに」 | （該当なし） |
| setup-matt-pocock-skills | Mattスキル群自体のper-repo設定 | 初回導入時 | （不要・別体系） |
| tdd | TDD・縦断スライス(tracer bullet) | 機能/バグをTDDで | test-driven-development |
| to-issues | プランを縦断スライスissue化 | プラン→タスク分解 | dev-cycle / feature-dev |
| to-prd | 会話文脈からPRD生成 | PRD作成 | feature-dev / brainstorming |
| triage | issue状態マシン運用(5状態) | issueトリアージ | （バックログ.md運用・合わない） |
| スキル | 一言目的 | トリガー | 筆者環境の類似 |
|---|---|---|---|
| caveman | 超圧縮通信でトークン約75%削減 | 「caveman mode」「be brief」 | （該当なし・新規） |
| grill-me | 計画を執拗にインタビュー | 「grill me」 | brainstorming / teian |
| handoff | 会話をハンドオフdocに圧縮 | セッション引き継ぎ | new-session |
| teach | 学習ワークスペース(MISSION/lessons) | 「teach me」 | （該当なし・新規） |
| write-a-skill | 新規スキル作成 | 「skill作って」 | skill-creator / skill-test |
| スキル | 一言目的 | 備考 |
|---|---|---|
| git-guardrails-claude-code | 危険gitコマンド(push/reset --hard等)をブロックするhook | 実用性高・筆者は既存セキュリティガードhook相当あり |
| setup-pre-commit | Husky pre-commit(lint-staged/Prettier/型检查/test) | プロジェクト次第 |
| migrate-to-shoehorn | TSの as 型アサーションを shoehorn に移行 | TypeScript特化・筆者不使用 |
| scaffold-exercises | 演習ディレクトリ(問題/解答/解説)をscaffold | 教材作成向け |
| スキル | 分類 | 一言目的 |
|---|---|---|
| edit-article | personal | 記事を章構成改善・文章練り上げ |
| obsidian-vault | personal | Obsidianノート検索・作成・管理 |
| review | in-progress | 変更をStandards/Spec 2軸でレビュー(並列サブエージェント) |
| writing-beats / writing-fragments / writing-shape | in-progress | 記事執筆系(ビート構成/フラグメント採掘/成型) |
| design-an-interface / qa / request-refactor-plan / ubiquitous-language | deprecated | 廃止済(インターフェース設計/QA/リファクタ計画/用語辞書生成) |
engineering(10) + productivity(5) + obsidian-vault の核心16個を深掘りします。各カードをクリックで展開。高中低＝適合度、○△✕＝取り込み推奨（第4部の詳細評価と同じ）。
知らないコード領域に入った時、上位レイヤーの抽象度に上がって「関連する全モジュールと呼び出し元の地図」を、プロジェクトのドメイン用語で出させます。たった7行の最小スキル。
「この辺りのコード、全体像が分からない」「zoom out」と言った時。disable-model-invocation: true なので明示呼び出し専用。
1発言 → エージェントが抽象度を1つ上げてモジュール・caller一覧を提示。詳細実装には踏み込まず「地図」だけ。
深掘りする前にまず「地図」を持つ。全体構造が見えないまま部分を読む無駄を防ぐ。
NexusCore の特定ファイルを読む前に「zoom out」→ 関連モジュールの関係図を先に把握。ただし筆者は Explore エージェントで同等ことができるため取り込み優先度は△。
手強いバグの規律ある診断ループ。Phase 1〜6: フィードバックループ構築 → 再現 → 仮説3-5個 → 計測 → 修正+回帰テスト → クリーンアップ+ポストモーテム。各Phaseは明示的に正当化しない限りスキップ禁止。
「diagnose this」「debug this」・バグ報告・性能低下の報告。
Phase1が核心: 失敗テスト/curlスクリプト/CLI/ヘッドレスブラウザ/trace再現等10種のループ構築法を順に試し、高速で決定的なpass/fail信号を作る。「ループさえあればバグは90%直る」。
コードを睨むより再現ループを構築することが本質。ループ無しに仮説検証に入らない。「30秒のflakyループは無いよりマシ程度・2秒の決定的ループはデバッグの超能力」。
ヨツバの不具合・glm-rate-proxy の400エラー等の調査に適用可能。ただし筆者は superpowers:systematic-debugging で同等の規律があるため重複度高（△）。
grill-me の強化版。計画を執拗にインタビューしつつ、CONTEXT.md（用語辞書）とADR（アーキテクチャ決定記録）を会話中にインライン更新。用語の矛盾を即指摘。
計画・設計を、プロジェクトの既存ドメインモデルと言語に対してストレステストしたい時。
1問ずつ・推奨答え付き・コード探索優先。用語矛盾があれば「あなたのglossaryではXだが、Yと言ってる−どちら？」と即指摘。用語が確定したらその場でCONTEXT.md更新。ADRは「変更困難・文脈無しで驚き・真のトレードオフ」の3つ全て満たす時だけ控えめに提案。
失敗モード#1（意図のズレ）+#2（用語のズレ）の同時対策。設計を詰めながら共有語彙を維持する。
新スキル設計時に「SSOTの用語と整合するか」を詰める用途。ただし筆者は brainstorming + SSOT（全体マップ_MOC・用語集）で同等の役割を担っているため△。
コードベースの「deepening機会（浅いモジュールを深いモジュールにする候補）」を発見し、自己完結のHTMLレポート（Tailwind+Mermaid・各候補にbefore/after図）を出力。
アーキテクチャ改善・テスト容易性向上・密結合モジュール統合・AIが巡回しやすいコードベース化。
① Explore サブエージェントで摩擦を探す（削除テスト: そのモジュールを消したら複雑度が消えるか、それともN個所に再現するか）→ ② 候補をHTMLレポート出力・開く → ③ ユーザーが候補を選んだらグリリングで深掘り。
「深いモジュール＝小さなinterfaceの裏に大きな振る舞い」(John Ousterhout流)。浅いモジュール（interface ≒ 実装）を深くして、テスト容易性とAI巡回性を両立。
NexusCore 等、ある程度規模のある自分プロジェクトの構造改善に有用。筆者環境に相当スキルなし・学習価値も高いので○。ただし現在の個人開発規模だと適用機会は限定的。
使い捨てプロトタイプで設計を検証。「答える質問」で2分岐: ロジック/状態モデル検証なら対話的端末アプリ、UI検証なら1ルートで切替可能な複数のラディカルに異なるUI。
「prototype this」「試しに遊んでみたい」「データモデルを健全性チェック」「いくつかデザイン試して」。
質問判定 → 1コマンドで実行できるthrowaway実装（永続化なし・テストなし・仕上げなし）→ 全状態を表示 → 答えが得られたら削除 or 本体に取り込み。
「プロトタイプは質問に答える使い捨てコード」。「学ぶために速く作って消す」が目的。prodのコード規範を当てない。
新しい楽曲スキルのUI案・HTMLガイドのレイアウト案出しに使える。筆者環境に相当なし・便利だが、現在の作業パターン（スキルで十分）を考えると△。
Mattスキル群自体のper-repoセットアップ。issue tracker（GitHub/GitLab/ローカルmarkdown）・triageラベル語彙・ドメインdoc配置を docs/agents/ に書き出し、CLAUDE.md/AGENTS.md に Agent skills ブロックを追加。
Mattのengineeringスキル（triage/to-issues/to-prd/diagnose等）を初めて使う前、あるいは「スキルがissue trackerの文脈を持っていない」時。
探索 → 3決定を1つずつ（A:issue tracker / B:5つのtriageラベル文字列 / C:ドメインdoc単一or複数コンテキスト）→ ドラフト確認 → 書き込み。
triage/to-issues等が前提とする設定（どのissue trackerか・ラベル文字列は何か）を生成するメタスキル。
筆者は独自スキル体系+SSOT+バックログ.md運用で、Mattのengineeringスキル群をそのまま採用しない予定。よって✕。
TDD（red-green-refactor）。最大の特徴: 水平スライス禁止・縦断スライス(tracer bullet)強制。「全テスト書いてから全実装」はクソテストを生むと断じる。
「red-green-refactor」・統合テスト希望・テストファースト。
計画 → tracer bullet（1テスト→1実装で経路全体を証明）→ 残り各振る舞いを RED→GREEN ループ → GREEN維持でrefactor。
良いテストは「公開interface越しに振る舞いを検証」し、リファクタで壊れない。内部詳細に結合したテストは悪。「水平に全部テスト書く」のは想像上の振る舞いをテストしてしまい実振る舞いに鈍感になる。
筆者は superpowers:test-driven-development で同等を保持。重複のため✕。
プラン/PRDを tracer-bullet縦断スライスでissue化。各スライスは「全統合層を端から端まで貫く薄い完全パス」。HITL（人介入要）かAFK（無人可）かを付与。AFK優先。
プラン→実装issue分解・作業分割。
コンテキスト収集 → コード探索 → 縦断スライス案（タイトル/HITL or AFK/blocked by/ユーザーストーリー）を提示 → ユーザー承認まで反復 → 依存順にissue公開。
層別（水平: schema全部→API全部→UI全部）ではなく、垂直に全層を貫く薄いスライスで独立して掴める・単体で検証可能。ファイルパス・コード断片は書かない（陳腐化防止）。
筆者の dev-cycle（Issue化フェーズ）/ feature-dev で同等の分解を行う。HITL/AFK・縦断スライスの思想は参考になるが△。
会話の文脈とコード理解から PRD（製品要件定義）を合成してissue trackerへ公開。ユーザーにインタビューしない・既知情報を合成するだけ。
「PRD作って」・現在の文脈から要件定義を出したい時。
コード探索 → テストseams（既存優先・最高位）を確認 → PRDテンプレ（問題/解決/ユーザーストーリー長大リスト/実装決定/テスト決定/スコープ外）で作成 → ready-for-agent ラベルで公開。
インタビューは grill 側で済ませる前提。PRDは合成専門。ファイルパス・コード断片は書かない（prototype由来の決定エンコード部分だけ例外）。
筆者の feature-dev / brainstorming で要件定義を行う。テンプレ構造（問題文/ユーザーストーリー/スコープ外明記）は参考になるが△。
issueを5状態のステートマシンで運用: needs-triage（要評価）/ needs-info（報告者待ち）/ ready-for-agent（AFK実装可）/ ready-for-human（人実装）/ wontfix。+ bug/enhancement の2カテゴリ。
「要注意を見せて」・特定issueのトリアージ・受信バグ/要望レビュー。
3バケツ（未ラベル/needs-triage/報告者活動ありneeds-info）を最古順提示 → 個別に文脈収集→推奨→（バグなら）再現→（必要なら）grill → 状態適用。AIトリアージコメントには必ず「This was generated by AI during triage.」免責。
カノニカル状態名でissue流通を整理。.out-of-scope/ 知識ベースで過去の却下を記憶し再提案を防ぐ。
筆者は obsidian-ssot のバックログ.md ベース運用でGitHub issue重型ではなく、ワークフローが合わない。✕。
超圧縮通信モード。冠詞(a/an/the)・冗長語・定型句・ hedge を削り、トークン使用量を約75%削減。技術的正確性・コード・エラーは完全維持。
「caveman mode」「talk like caveman」「less tokens」「be brief」。
1トリガーで以降全レスポンスで常時ON（戻さない・filler drift防止）。「[thing] [action] [reason]. [next step].」パターン。危険操作確認・多段順序の時だけ一時解除して解除後に復帰。
トークン節約。ただし技術用語は正確・コードブロック不改変・エラー正確引用。「security warning・破壊的操作確認」では自動的に通常語に戻す安全装置付き。
筆者環境は GLM-5.2（1M窓）だが、長時間作業・大量処理でトークン節約の価値は大きい。筆者環境に相当スキルなし・○。例: 「Bug in auth middleware. Token expiry check use < not <=. Fix:」
計画・設計について容赦なくインタビューし、合意に達するまで決定木の各分岐を1つずつ解決。各問に推奨答えを付ける。
「grill me」・計画をストレステストしたい時・設計を練りたい時。非コード用途（コードは grill-with-docs）。
質問は1度に1つ。各問に推奨答え提示。コード探索で答えられるものは探索する。
失敗モード#1（意図のズレ）の対策。作業を始める前に合意形成する。Mattの最も人気のスキル。
筆者の brainstorming / teian と重複。ただし grill-me は「relentlessly・1問ずつ・推奨答え付き」でより轻量・即効。既存で足りるため△（差し替え候補としては有力）。
現在の会話をハンドオフ文書に圧縮し、新しいエージェントが作業を継続できるようにする。OS一時dirに保存（workspace外）。「suggested skills」セクション付き。
セッション引き継ぎ・コンテキストが肥大化した時。
会話要約 → 一時dir保存 → 既存アーティファクト（PRD/plan/ADR/issue/commit/diff）の重複書きをせず参照 → 機密情報（API鍵等）マスキング。
セッション間引き継ぎ。「重複書きせず参照」で情報の陳腐化を防ぐ。
筆者の new-session スキルが全く同じ役割（引き継ぎプロンプト生成）。完全重複のため✕。
学習ワークスペースを構築し、ユーザーにスキル/概念を教える。状態を複数ファイルで管理: MISSION.md（学習の理由）・reference/*.html（チートシート）・learning-records/*.md（学習記録=ADR相当）・lessons/*.html（1完結lesson）。最近接発達帯で教える。
「teach me」・学習開始。argument-hint: "What would you like to learn about?"
MISSION把握 → 高品質リソース収集(RESOURCES.md)・パラメトリック知識を信じない → lesson HTML生成（短く・1つの勝利・タイムリー）→ 参照doc生成（用語集）→ コミュニティ提案（知恵）。
深い学習に必要な3要素: 知識（高品質リソース）・スキル（インタラクティブlesson）・知恵（コミュニティ）。検索練習・間隔反復・インターリービングで長期定着（fluencyでなくstorage strength）。
筆者のキャリア評価で最優先課題「Python基礎学習（コード読解力）」に直結。筆者環境に相当なし・○。学習の単位（MISSION/lesson/learning-record）設計はSSOTの記録思想と通底。
新しいエージェントスキルを作成。適切な構造・progressive disclosure・バンドルリソース。
「skill作って」・「build a new skill」。
要件ヒアリング（タスク/ユースケース/スクリプト要否/参照資料）→ ドラフト（SKILL.md+必要に応じてreference/scripts）→ レビュー。
descriptionはエージェントがスキル選択時に見る唯一の情報。「何をするか＋Use when [トリガー]」を1024字以内で。SKILL.mdは100行以下・時間依存情報なし・参照は1階層まで。
筆者の skill-creator / skill-test / 標準 superpowers:writing-skills で同等以上。description要件の指針は参考になるが✕。
Obsidian vault内のノートを検索・作成・管理。wikilink（[[ ]]）とindexノードで編成。Mattのvaultはルートほぼフラット。
Obsidianノートの検索・作成・整理。
vault場所・命名（Title Case）・wikilink・index探索（find -name "*Index*"）。バックリンク検索は grep -rl "\[\[Note\]\]"。
フォルダ階層ではなくリンクとindexノードで編成する思想。ノートは学習の1単位。関連ノートを末尾にリンク。
筆者の obsidian-ssot と同じObsidian運用だが、アプローチが異なる: Matt=フラット+リンク/index、筆者=フォルダ階層（00_SYSTEM/01_DECISIONS等）+MOC。両思想の比較は示唆に富むが、機能は ssot-record / ssot-search / 全体マップ_MOC で充足・△。
全29スキルを、筆者の既存スキル（自作26 + superpowers 14 + 標準）と比較し採点。適合度は既存スキルとの重複度で決定。
判定基準: 高＝既存に相当なし・筆者ワークフローに直接効く ／ 中＝既存と似ているがアプローチ違い ／ 低＝既存でほぼ同等。推奨: ○入れる ／ △様子見 ／ ✕既存で十分。
| スキル | 適合 | 推奨 | 理由 |
|---|---|---|---|
| teach | 高 | ○ | 学習ワークスペース（MISSION/lesson/learning-record）。既存に相当なし。Python基礎学習（キャリア最優先課題）に直結。 |
| caveman | 高 | ○ | トークン約75%削減の圧縮通信。既存なし。GLM-5.2(1M窓)環境で長時間作業・大量処理の省トークンに実用。安全装置付き。 |
| スキル | 適合 | 推奨 | 理由 |
|---|---|---|---|
| improve-codebase-architecture | 高 | △ | 学習価値大・既存なし。ただし現在の個人開発規模だと適用機会限定的。規模が大きくなったら○。 |
| grill-me | 中 | △ | brainstorming/teianと重複。ただし「relentlessly・1問ずつ・推奨答え付き」で轻量即効。teianの差し替え候補。 |
| grill-with-docs | 中 | △ | brainstorming+SSOTで同等。CONTEXT.mdインライン更新の規律は参考。 |
| diagnose | 中 | △ | systematic-debuggingと重複。「フィードバックループ構築10法」は参考。 |
| to-issues | 中 | △ | dev-cycle/feature-devと重複。縦断スライス・HITL/AFK思想は参考。 |
| to-prd | 中 | △ | feature-dev/brainstormingと重複。PRDテンプレ構造（スコープ外明記）は参考。 |
| prototype | 中 | △ | 既存なし・便利。ただし現在の作業パターン（スキルで十分）を考慮。 |
| zoom-out | 中 | △ | Exploreエージェントで代替可。7行の軽さは魅力的。 |
| obsidian-vault | 中 | △ | ssot-record/ssot-searchで充足。Mattの「フラット+リンク」vs筆者「フォルダ階層+MOC」思想比較で示唆。 |
| edit-article | 中 | △ | zenn-article-pipelineと重複。「DAGで章依存を整理」は参考。 |
| git-guardrails (misc) | 中 | △ | 既存セキュリティガードhook相当あり。hook設計の参考。 |
| review (in-progress) | 中 | △ | code-review/標準reviewと重複。Standards/Spec 2軸並列は参考。 |
| writing-* (in-progress) | 低 | △ | 執筆系ドラフト。zenn-article-pipelineの参考程度。 |
| スキル | 適合 | 推奨 | 理由 |
|---|---|---|---|
| handoff | 低 | ✕ | new-sessionスキルと完全重複。 |
| tdd | 低 | ✕ | superpowers:test-driven-developmentと重複。 |
| write-a-skill | 低 | ✕ | skill-creator/skill-test/writing-skillsと重複。 |
| setup-matt-pocock-skills | 低 | ✕ | 独自体系+SSOT運用のため不要。 |
| triage | 低 | ✕ | バックログ.md運用でワークフローが合わない。 |
| setup-pre-commit (misc) | 低 | ✕ | プロジェクト次第・現在不要。 |
| migrate-to-shoehorn (misc) | 低 | ✕ | TypeScript特化・不使用。 |
| scaffold-exercises (misc) | 低 | ✕ | 教材作成向け・現在不要。 |
| deprecated 4件 | 低 | ✕ | 廃止済（ubiquitous-language等はCONTEXT.mdに統合）。 |
結論サマリー: 筆者環境に取り込む推奨は teach と caveman の2つ（○）。どちらも既存に相当しない新規領域（学習フレームワーク・トークン圧縮）。grill-me は teian の差し替え候補。残り大半は既存スキル/superpowers/標準で充足され、丸ごとプラグイン導入は不要。「 Matt の思想（small/adaptable/composable・CONTEXT.md・grilling）」を既存のSSOT運用・スキル設計に取り入れる方が、個別スキル移植より価値が大きい。