setup-matt-pocock-skills

リポジトリに関わる作業を始める前に、対象リポジトリに WORK-ROUTING.md がある場合は読んでください。このスキルのソースツリーでも、セットアップ時に対象リポジトリ内のコピーを作成する際に使う共通のポインターとルールを定義している、同梱の ../../WORK-ROUTING.md を読んでください。

Matt Pocock のスキルをセットアップする

エンジニアリングスキルが前提とする、リポジトリごとの設定をひな形から作成します。

• 課題トラッカー — 課題の管理場所（デフォルトは GitHub。ローカルの Markdown も標準でサポートされています）
• トリアージラベル — 5 つの標準トリアージ役割に使う文字列
• ドメインドキュメント — CONTEXT.md と ADR の保存場所、およびそれらを読み込む際のルール
• Work Routing ドキュメント — オリエンテーション、レーン、計画、ランタイム／プロトコルの境界、コンテンツ／パッケージの境界を管理する、正規のプロジェクトドキュメント一式

これはプロンプト駆動型のスキルであり、決定論的なスクリプトではありません。調査し、見つかった内容を提示し、ユーザーに確認してから書き込みます。

プロセス

1. 調査

現在のリポジトリを確認し、初期状態を把握します。存在するものはすべて読み、決めつけないでください。

• git remote -v と .git/config — GitHub リポジトリですか？どのリポジトリですか？
• リポジトリルートの AGENTS.md と CLAUDE.md — どちらか存在しますか？どちらかに ## Agent skills セクションはありますか？
• リポジトリルートの CONTEXT.md と CONTEXT-MAP.md
• docs/adr/ と、存在する場合は src/*/docs/adr/ ディレクトリ
• docs/agents/ — このスキルの以前の出力がすでにありますか？
• WORK-ROUTING.md — 対象リポジトリ内にルーティングポインターはすでにありますか？
• Work Routing のパスが存在する場合は、ARCHITECTURE.md、docs/README.md、docs/process/DEVELOPMENT.md、docs/issues/ROADMAP.md、PLANS.md、docs/architecture/RUNTIME.md、docs/architecture/NETCODE.md、docs/architecture/CONTENT.md
• .scratch/ — ローカル Markdown の課題トラッカー規約がすでに使われている兆候
• triage スキルがインストールされていますか？（このスキルと同じ場所に triage スキルのフォルダーがあるか、利用可能なスキルに triage があるか。）これによってセクション B を実行するかどうかが決まります。
• モノレポの兆候 — pnpm-workspace.yaml、package.json の workspaces フィールド、または独自の src/ を持つ、中身のある packages/*。これらは本当に大規模なマルチパッケージリポジトリに限られます。存在しなければ、ほとんどのリポジトリと同様に単一コンテキストです。

2. 調査結果を提示して質問する

存在するものと不足しているものを要約します。その後、セクションを順番に進めます。1 セクションにつき回答を 1 つ受け取り、その後に次のセクションへ進みます。

各セクションでは、ユーザーが一言で承認できるよう、推奨する回答を先に示します。選択肢によって実質的に分岐する場合に限り、説明を 1 行添えます。調査ですでに決まっている場合は、そのセクションを省略します（triage がインストールされていない場合のセクション B、モノレポでない場合のセクション C）。

セクション A — 課題トラッカー。

説明：このリポジトリで課題を管理する場所が「課題トラッカー」です。to-tickets、triage、to-spec などのスキルは、課題トラッカーから情報を読み書きするため、gh issue create を実行するのか、.scratch/ の下に Markdown ファイルを書くのか、あるいは別のワークフローに従うのかを把握する必要があります。このリポジトリで実際に作業を管理している場所を選んでください。

基本方針として、これらのスキルは GitHub 向けに設計されています。git remote が GitHub を指している場合は、GitHub を提案します。git remote が GitLab（gitlab.com またはセルフホストのホスト）を指している場合は、GitLab を提案します。それ以外の場合（またはユーザーが希望する場合）は、次の選択肢を提示します。

• GitHub — 課題はリポジトリの GitHub Issues で管理します（gh CLI を使用）
• GitLab — 課題はリポジトリの GitLab Issues で管理します（glab CLI を使用）
• ローカル Markdown — 課題をこのリポジトリの .scratch/<feature>/ の下にファイルとして保存します（個人プロジェクトやリモートのないリポジトリに適しています）
• その他（Jira、Linear など）— ワークフローを 1 段落で説明してもらい、スキルが自由記述として記録します 選択内容を docs/agents/issue-tracker.md に記録します。GitHub と GitLab のテンプレートには「PR をリクエストの窓口として扱う」フラグがあり、デフォルトでは オフ です。オフのままにし、オンにしないでください。外部の PR をトリアージキューに含めたいユーザーは、後からファイル内のフラグを切り替えられます。

セクション B — トリアージラベルの用語集。 triage スキルがインストールされていない場合（探索で判明しています）は、このセクションを丸ごとスキップしてください。インストールされていないスキルにはラベルは必要ありません。

インストールされている場合は、次の質問をちょうど 1 つだけしてください。

デフォルトのトリアージラベルを使用しますか？（推奨：はい）

デフォルトは 5 つの標準的な役割で、それぞれのラベル文字列は名前と同じです：needs-triage、needs-info、ready-for-agent、ready-for-human、wontfix。はいの場合は、そのまま記述します。ユーザーが「いいえ」と答えた場合に限り（通常は、トラッカーで既に別の名前が使われているためです。例：needs-triage に対して bug:triage）、triage がラベルを重複作成せず、既存のラベルを適用するように上書き内容を収集します。

セクション C — ドメインドキュメント。 デフォルトは 単一コンテキスト（リポジトリのルートに 1 つの CONTEXT.md と docs/adr/）です。ほとんどすべてのリポジトリに適しているため、確認せずに記述します。

探索でモノレポの兆候が見つかった場合に限り、コンテキストごとの CONTEXT.md ファイルへのリンクをまとめたルートの CONTEXT-MAP.md を配置する 複数コンテキスト を提示します。そのうえで、どちらの構成にするか確認します。

セクション D — Work Routing ドキュメント。 このセクションは必須です。新しいレーン選択肢ではありません。次の正規オーナードキュメントと、ターゲットリポジトリ内のローカルな WORK-ROUTING.md ポインターを追加します。

ドキュメント	管轄内容
WORK-ROUTING.md	Work Routing 一式への共有ポインター。プロジェクトの主題は管轄しません
ARCHITECTURE.md	概要説明と変更のルーティング
docs/README.md	ドキュメントの管轄とルーティング
docs/process/DEVELOPMENT.md	レーンの選択と証明
docs/issues/ROADMAP.md	現在の作業キュー
PLANS.md	重要な計画と継続的な調整
docs/architecture/RUNTIME.md	ランタイムの管轄とライフサイクルの境界
docs/architecture/NETCODE.md	プロトコルと互換性の受け入れ境界
docs/architecture/CONTENT.md	サーバーに関連するリソースとクック／パッケージ化の境界

既に存在する項目だけを読みます。存在しない項目には work-routing/ 内のシードを使用し、プロジェクトの事実を創作するのではなく、初期セットアップ用のシードとして明記します。既存の項目はリポジトリの規範として扱い、保持したうえで追加案を示し、シードで置き換えないでください。既存のオーナードキュメントに記載がない、または古くなっている場合、新しいルールを適用する前に、範囲を限定した推論を記録するか、該当する正規オーナーを更新します。

この一式では、次の管轄ルールを保持する必要があります：docs/process/DEVELOPMENT.md がレーン選択を管轄し、PLANS.md が設計メモおよびチェックイン済みの計画に関する条件と内容を管轄します。別のルーティングルールを創作しないでください。文書のみの編集、小規模なオーナー非依存の修正、または部分的な進捗を理由に、適用される計画が要求していない限り、クローズ処理を開始しないでください。

3. 確認して編集する

次のドラフトをユーザーに提示します。

• 編集対象として選ばれた CLAUDE.md または AGENTS.md に追加する ## Agent skills ブロック（選択ルールについてはステップ 4 を参照）
• docs/agents/issue-tracker.md、docs/agents/domain.md、docs/agents/triage-labels.md の内容（最後のものは triage がインストールされている場合のみ）
• 不足している WORK-ROUTING.md ポインターと、work-routing/ 内の Work Routing オーナードキュメントに加え、既存の Work Routing ドキュメントに提案する、範囲を限定した追加内容

書き込む前に、ユーザーが編集できるようにします。

4. 書き込み

編集するファイルを選びます：

• CLAUDE.md が存在する場合は、これを編集します。
• そうでなく、AGENTS.md が存在する場合は、これを編集します。
• どちらも存在しない場合は、どちらを作成するかユーザーに確認します。こちらで選んではいけません。

CLAUDE.md がすでに存在する場合（または AGENTS.md がすでに存在する場合）は、もう一方のファイルを作成してはいけません。必ず、すでに存在するファイルを編集してください。

選択したファイルに ## Agent skills ブロックがすでに存在する場合は、重複して追加せず、その内容を該当箇所で更新します。周囲のセクションにあるユーザーの編集内容を上書きしてはいけません。

ブロック：

## Agent skills

### Issue tracker

[one-line summary of where issues are tracked]. See `docs/agents/issue-tracker.md`.

### Triage labels

[one-line summary of the label vocabulary]. See `docs/agents/triage-labels.md`.

### Domain docs

[one-line summary of layout — "single-context" or "multi-context"]. See `docs/agents/domain.md`.

triage がインストールされていて、セクション B が実行された場合に限り、### Triage labels サブブロックを含め、docs/agents/triage-labels.md を作成します。そうでない場合は、どちらも省略します。

次に、このスキルフォルダーにあるひな形を出発点として、ドキュメントファイルを作成します。

• issue-tracker-github.md — GitHub の課題トラッカー
• issue-tracker-gitlab.md — GitLab の課題トラッカー
• issue-tracker-local.md — ローカル Markdown の課題トラッカー
• triage-labels.md — ラベルのマッピング（triage がインストールされている場合のみ）
• domain.md — ドメイン文書の利用ルールとレイアウト

さらに、work-routing/ 内の該当ファイルをもとに、WORK-ROUTING.md と Work Routing のオーナー文書を作成します。必要に応じて親ディレクトリも作成してください。コピーするひな形は、対象パスにファイルが存在しない場合に限ります。対象がすでに存在する場合は、オーナーの意向を損なわない、確認済みの内容だけを追加してください。文書を上書きしたり、プロジェクト固有の指針を削除したりしてはいけません。生成するファイルには、未確認の製品、ランタイム、プロトコル、パッケージングに関する断定を含めないでください。

「その他」の課題トラッカーの場合は、ユーザーの説明をもとに docs/agents/issue-tracker.md を一から作成します。

5. 完了

セットアップが完了したことと、今後どのエンジニアリングスキルがこれらのファイルを参照するかをユーザーに伝えます。対象ローカルの WORK-ROUTING.md ポインターと、作成した Work Routing のオーナー文書、またはすでに存在していたため変更しなかった文書を明記します。今後も docs/agents/*.md と Work Routing の文書を直接編集できること、課題トラッカーの切り替え、ドメインレイアウトの変更、または不足しているセットアップ用ひな形の再生成を希望する場合に限り、このスキルを再実行すればよいことを伝えます。