目次
この記事のポイント
/setup-matt-pocock-skillsは prompt-driven で動作し、git remote と既存ファイルを読んでから書き込むdocs/agents/配下に書くのはissue-tracker.md/domain.md/triage-labels.mdの最大 3 ファイル- スキル本体は 変更しない、設定はリポジトリ単位でコミットされる（リポジトリ＝単一の真実の源）
- GitHub 以外も対応：GitLab / Local (.scratch/) / Other（Jira, Linear, Azure DevOps 等）すべて動く
01WHAT 「スキルを渡す」とは何を、どこに書くのか
生成 AI を日常的に使うようになると「エージェントにスキルを渡している」という言い回しをよく耳にします。しかしその実体——どのファイルがスキルで、どこに置かれ、誰がいつ書き換えるのか——は曖昧なままになりがちです。同じプロンプトを与えても、ある日エージェントが GitHub Issues に issue を立て、別の日にはローカル Markdown に書き出し、3 日目には Linear にチケットを作る——そんな経験を一度でもすると、運用の怖さが分かります。
Matt Pocock が公開している /setup-matt-pocock-skills は、この「エージェントがどこに何を書くか」という 1 点だけを、リポジトリ単位で確定させるためのセットアップスキルです。スキルの本体は一切編集しません。代わりに、リポジトリ内に「エージェントへの設定書」を 3 ファイルだけ書き残します。設定書は markdown なので人間が読めて、エージェントも実行時に読んで動きます。
スキルの本体は不変、設定だけがリポジトリごとに違う
ポイントは「スキル＝共通、設定＝リポジトリごと」という分離です。コードベースで言えばスキルはライブラリ、設定は .env のようなもの。1 度 setup-matt-pocock-skills を走らせると、それ以降の /triage・/to-spec・/to-tickets・/wayfinder は同じ docs/agents/issue-tracker.md を読み、毎回「あなたの環境ではどこに書けばいいか」を聞く必要がなくなります。
この設計は、設定がユーザー単位やグローバルではなくリポジトリ単位であることも意味します。会社ごとに違う業務ルール、案件ごとに違うチケット運用、現場ごとに違うラベル体系——それらすべてが repo の docs/agents/ に置かれ、git で履歴が残ります。エージェントが混乱するたびに人間が言い訳をする必要がなくなります。
「prompt-driven」と「deterministic script」の違い
/setup-matt-pocock-skills はシェルスクリプトではなく、LLM 自身が git remote や既存ファイルを読んで提案するプロンプト駆動型です。メリットは「外部状況を読んで人間と相談できる」、デメリットは「決定論的に動かない」点。ただし書き出す内容は markdown ファイルなので、提案を受けて人間が手で微調整できます。
GitHub にロックされているわけではない
「Matt Pocock のスキルは GitHub Issues前提なのでは」という疑問をよく目にします。実際は逆で、issue-tracker.md が指す先は 4 種類から選べます。GitHub / GitLab / Local markdown（.scratch/<feature>/ 配下）/ Other の 4 択で、最初の 3 つは同梱テンプレートをそのまま動かせます。Other は Jira・Linear・Azure DevOps・Beads など任意のワークフローを prose で書き下す方式で、既に Jira over MCP や Gitea CLI、独自 local dashboard の事例がコミュニティで共有されています。
Local markdown は「リモートがない個人開発」の正式対応であり、フォールバックではありません。GitHub Issues と Local markdown はどちらかに決める関係で、両方を重ねると二重管理になります。逆に、Other 経由で独自ワークフローを文書化すれば、既存のチケット運用を変えずに AI を組み込めます。
02POINTS /setup-matt-pocock-skills を 5 ステップで回す
ここからは /setup-matt-pocock-skills を実際に動かすときの手順を 5 ステップで整理します。多くの現場では 2 回の確認で終わる軽いフローですが、既存のラベル体系や monorepo 構造がある場合に分岐するポイントがあるので、順番に追っていきましょう。
- ①実行タイミングを決める新しいリポジトリで他のスキル（
/triage・/to-spec・/to-tickets・/wayfinder）を初めて使う前に 1 回だけ実行します。すでにプロジェクトが進行中でも問題ありません。スキルは現在のgit remoteと既存CONTEXT.mdを読んでから書くため、過去の作業は引き継がれます。 - ②プロンプト駆動の提案を受ける
/setup-matt-pocock-skillsは git remote を読み取り、リポジトリに対応する issue tracker を提案します。プロジェクトが半分進んだ状態でも、既存ファイルを尊重した提案が出るため「設定を全部上書きされた」という事故は起きません。 - ③Issue tracker の 4 択から選ぶGitHub / GitLab / Local markdown（.scratch/ 配下）/ Other のいずれを選びます。GitHub / GitLab はそれぞれ
gh/glabCLI が必要です。Local markdown はリモートがないソロプロジェクト用の正式対応で、何も追加インストールは不要です。 - ④Domain docs の構造を確認するスキルが monorepo 兆候を検知した場合のみ、multi-context の
CONTEXT-MAP.mdを提案します。それ以外（単一リポジトリ）ではCONTEXT.md+docs/adr/の組み合わせを既定として記録します。/domain-modelingが後からここを埋めていきます。 - ⑤書き込み結果を確認するdocs/agents/ 配下に 3 ファイル（
issue-tracker.md・domain.md・triage-labels.md、triage を入れていない場合は 2 ファイル）と、CLAUDE.mdまたはAGENTS.mdの## Agent skillsブロックが生成されているか目視で確認します。スキル本体（SKILL.md）が編集されていないことも必ず見てください。
triage-labels.md は「ラベルを作る」ファイルではない
triage-labels.md は GitHub リポジトリのラベルを生成しません。書かれるのは「5 つの標準ラベル（needs-triage / needs-info / ready-for-agent / ready-for-human / wontfix）」とトラッカー上のラベルの対応表だけです。新規 GitHub リポジトリで gh label create を 1 回も実行していない場合、初回 /triage 実行時に gh issue create --label <missing> が失敗します。先に手動でラベルを作成しておくと安全です。
GitHub 以外で動かすときの確認ポイント
GitLab を使う場合は glab CLI がインストール済みであること、Local markdown を使う場合は .scratch/ ディレクトリのパーミッションが許容されることが前提です。Other（Jira / Linear / Azure DevOps）を選ぶ場合は、トラッカーの操作方法（issue 作成のコマンド、認証、ラベル体系）を 1 段落で issue-tracker.md に書きます。スキル側は prose を実行時に読んで動くため、トラッカーが何であれ同じフローで運用できます。
03INSIGHT ADT の SAP×AI 案件に skills 設計を持ち込む
Matt Pocock 流の単一リポジトリ設計は、SAP×AI のような業務ドメインが複雑な領域でこそ効きます。SAP の世界では「会社コード」「購買組織」「販売組織」「プラント」「与信範囲」など、暗黙の前提が階層的に積み上がる構造が前提業務になります。AI エージェントに毎回その前提をプロンプトで説明するのは無理筋で、docs/agents/ に書いて共有する方がはるかに安くなります。
ADT では、案件ごとに SAP モジュール構成（FI/CO/MM/SD/PP/PM/BW など）と業務ルールが異なるため、docs/agents/domain.md にモジュール別の業務前提をまとめ、issue-tracker.md には Jira か GitHub Issues か案件の運用ルールを書き込みます。docs/agents/triage-labels.md は案件横断で標準化されたラベル（要確認・要件明確・実装待ち・検証待ち・保留）を割り当てる対応表として使っています。
AI エージェントの実行基盤は SAP AI Core／Generative AI Hubとは？BTP上でLLMを安全に使う仕組み で、LLM の応答を業務に翻訳する層は SAP BTP CAP入門：Cloud Application Programming Modelで作るS/4HANA拡張アプリ で解説しています。ローカル LLM で社外秘データを守りながら運用する場合は ローカルLLMで実現する、安全なSAP×AI活用 が参考になります。エージェントとワークフローの役割分担は AIエージェントとワークフローの使い分け で整理しています。
豆知識：「Config is death」という設計思想
Matt Pocock の設計には「設定が増えると死ぬ」という思想があります。/setup-matt-pocock-skills が設定するのは「tracker / labels / domain docs レイアウト」の 3 項目だけ。質問形式・トーン・グラリング頻度といった個人設定はあえてここに置かず、ユーザーが CLAUDE.md に書くべき項目として残しています。これは「設定が一箇所に集中すると、変更のたびに壊れる」という経験則からきています。
まとめ
/setup-matt-pocock-skillsは prompt-driven で、git remote と既存ファイルを読んでから書く。スキル本体は一切編集しないdocs/agents/配下に書くのはissue-tracker.md/domain.md/triage-labels.mdの最大 3 ファイルCLAUDE.mdまたはAGENTS.mdに## Agent skillsブロックを追加し、各ファイルへの 1 行サマリを置く- GitHub / GitLab / Local (.scratch/) / Other（Jira・Linear 等）が動く。「GitHub 専用」は誤解
- 再実行は基本的に不要だが、スキル側の seed テンプレが変わった場合は安易な再実行で整合性を取り戻せる
- 個人設定（トーン・質問形式・グラリング頻度）はここに書かず、CLAUDE.md に書く
04FAQ よくある質問
/setup-matt-pocock-skills は GitHub 専用ですか？
いいえ。GitHub / GitLab / Local markdown（.scratch/ 配下）/ Other（Jira・Linear・Azure DevOps 等）が同梱テンプレートで動きます。Other は独自ワークフローを prose で issue-tracker.md に書く方式で、既に Jira over MCP / Gitea CLI / 独自ダッシュボードの事例がコミュニティで共有されています。Local markdown は「リモートなし」の個人開発向けに用意された正式対応で、フォールバックではありません。
スキルファイル自体を編集する必要はありますか？
いいえ。スキル本体はリポジトリ横断で同一のまま、docs/agents/issue-tracker.md を実行時に読んで動きます。「私のプロジェクトでは…」と指すためにスキル側を書き換える必要はありません。設定は markdown で公開されているので、ユーザーが手で読んで調整できます。
CLAUDE.md と AGENTS.md のどちらに書かれますか？
既存ファイルがあれば編集、なければ「どちらを作るか」を聞いてから作ります。注意点として、Claude Code から残った CLAUDE.md が Codex 環境にもある場合、Codex は CLAUDE.md を読まないため Agent skills ブロックが反映されません。回避は AGENTS.md を正本にし、CLAUDE.md を 1 行で指す形に揃える方法です。
バージョンを上げたら再実行すべきですか？
基本は不要ですが、スキル側の seed テンプレートが変わった場合、古い docs/agents/ の記述が現在のスキルと食い違うことがあります。downstream スキル（/triage・/to-spec 等）の挙動が docs と違うと感じたら、安価な直し方は再実行です。再実行は現在のファイルを尊重して提案するため、過去の作業は失われません。
出典・参考
- aihero.dev — /skills/setup-matt-pocock-skills（Matt Pocock） https://www.aihero.dev/skills-setup-matt-pocock-skills
- aihero.dev — /skills（Matt Pocock、エンジニアリング flow 一覧） https://www.aihero.dev/skills
- GitHub — total-typescript/standup-issues 等 Matt Pocock リポジトリでの利用例 https://github.com/total-typescript
- aihero.dev — /ai-coding-dictionary（関連用語：agent・harness・ticket・grilling） https://www.aihero.dev/ai-coding-dictionary
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-09-27）の情報です。Matt Pocock 流のセットアップ手法は活発に更新されており、最新仕様は原文（aihero.dev）でご確認ください。考察部分は当社の見解であり、特定のスキル・運用を推奨するものではありません。