mattpocock/skills: A complete AI Coding workflow, end-to-end

▶ 元動画を見る

概要

Matt Pocock氏が、GitHub 16.2万スター・750万DLを誇る自身のskillsリポジトリ（mattpocock/skills）の基本ワークフローを解説したチュートリアル。npx skills@latest add mattpocock/skills によるインストールから、grill with docs → to spec → to tickets → implement → code review という「アイデアから出荷まで」の一連の流れを、実際の自作CLIリポジトリで実演している。既存コードベースでも新規プロジェクトでも同じ手順で導入できる。

主なポイント

• インストールは npx skills@latest add mattpocock/skills（Vercel製 skills.sh インストーラ、Node.js必須）。38スキルが見つかり、mattpocock/skills グループが公式に「良い」と判断されたもの、other skills は実験中で将来削除される可能性がある。
• Claude Code / Cursor / Codex など複数エージェントに対応。インストールスコープはチーム開発ならプロジェクト単位（全員が同じスキルセットを共有し共同改善できる）、ソロなら global。配置方式は symlink 推奨。
• 他のskillsリポジトリとの最大の違いは「ほぼすべてがユーザー起動型（user invoked）」であること。説明文が短く精密なため、38スキル全部入れてもコンテキスト消費はわずか660トークン。
• 導入後は setup mattpocock skills を実行。イシュートラッカー（GitHub / ローカルMarkdown / Jira / Linear / Beads など任意）、トリアージ用ラベル、ドメインドキュメント（context.md + ADR）の構成を対話で決める。Jira等への対応は「Jiraで設定して」と伝えるだけで既に動く。
• 迷ったら ask Matt スキル。作者本人を模したスキルで、skillsリポジトリの全体像と「まず何をすべきか」を答えてくれる。
• メインフローは①grill with docs（曖昧なアイデアを質問攻めで詰める。リポジトリ内ではステートフルで context.md / ADR に学習内容を記録）②必要なら prototype（会話だけでは決着しない、実行して確かめる必要がある問いに使う）③複数セッションにまたがる規模なら to spec / to tickets ④implement ⑤code review。
• 作業量が1セッションで収まるなら②③を飛ばして /implement this に直行してよい。判断軸は「1つのコンテキストウィンドウで終わるか」。
• spec は「最終的にどうなっているか（ゴール）」、tickets は「そこへどう辿り着くか（経路）」。各チケットは1コンテキストウィンドウ＝1セッション分の粒度に切る。実例では1つのspecに11のサブチケットがぶら下がっていた。
• code review は2軸で行う。(1) 実装が元のspecの受け入れ基準を満たしているか (2) リポジトリの標準ドキュメントに沿っているか（無ければMartin Fowler的なコードスメル基準を使用）。
• レビューを必ずサブエージェントで走らせるのが重要。自分で書いたコードをメインエージェントに直させると「良い出来だ」と甘く評価してしまうため、クリーンなコンテキストの別エージェントに見せる。

実践に使えること

• 導入: 空ディレクトリでも既存リポジトリでも npx skills@latest add mattpocock/skills → 公式グループを全選択 → 使用エージェント選択 → スコープ選択 → symlink。続けてエージェント内で setup mattpocock skills を実行し、イシュートラッカーを「ローカルMarkdownで」等と指定する。
• 曖昧な要望から始めてよい: 「このCLIから内部ツールを大体削って公開向けだけにしたい」程度のざっくりした一言で grill with docs を起動する。詳細を書き込むのはユーザーではなくスキル側の仕事で、6〜20問の質問で計画に落ちる。
• コンテキスト予算を意識する: 140kトークンを「スマートゾーン」の上限と見なし、それを超えると注意力低下・幻覚が増えると想定して作業を分割する。「残り100kで10コマンド削除なら余裕」といった見積もりで直行 implement か spec 分割かを決める。
• チケットは1つずつ実装し、間で毎回コンテキストをクリアする。「全チケットやって」とは言わない。余裕があれば1つだけ追加で詰め込む程度に留める。
• AIの提案を鵜呑みにしない: to tickets が3スライスに分割してきても「1スライスで足りる、1つにまとめて」と押し返してよい。
• 仕上げ: 全チケット実装後に spec との突き合わせレビューを最終パスとして必ず実行する。チケットで抜けた要件や未指定事項をここで回収できる。
• 音声入力（Whisper Flow等）を使うと、grillingの質疑応答のような対話量の多い工程が高速になる。