setup-repo

リポジトリをセットアップする

リポジトリを一度設定しておけば、ほかのすべてのスキルが推測することなく、その回答を参照できます。出力されるのは、docs/agents/ 配下のエージェント向け設定ファイル、シード仕様ファイル、およびリポジトリのエージェント向け指示に追加するポインターブロックです。

これはスクリプトではなく、対話形式で進めます。調査し、見つかった内容を提示し、ユーザーと一度に一つずつ決定してから、書き込みます。

テンプレートのシードは、このスキルセットの templates/ ディレクトリにあります。プラグインとしてインストールされている場合は ${CLAUDE_PLUGIN_ROOT}/templates、そうでない場合はこの SKILL.md からの相対パス ../../../templates として解決します。

進捗を記録する

このスキルには7つのステップがあり、ステップを飛ばすことがよくある失敗につながります。設定されていないトラッカーや、一度も実行されないステップ6の検証ゲートなどです。ステップ1の前に、以下の番号付きステップごとにTODOを作成し、順番に完了してください。各ステップの 完了条件 を満たした場合にのみ、チェックを付けます。ステップ6（設定が機能することの確認）は省略できません。

1. セットアップ状態を確認する

このステップで行うのは、リポジトリがこのスキルセット向けにすでに設定されているか、またその設定がどこまで完了しているかを確認することだけです。リポジトリ内のファイルのみを読み取ります。外部サービスやその認証情報を調べてはいけません（gh auth、gh label list、glab、Linear MCP の呼び出しは禁止）。また、ユーザーのシェル環境を読み取ってはいけません（env や *_API_KEY の確認は禁止）。ここで検出を行うことが目的ではありません。ステップ2で何を設定するかはユーザーが決定し、サービスやツールチェーンの具体的な情報は、ユーザーがすでに決定した内容に沿って、後の段階で収集します。

セットアップの目印を確認します。すべてリポジトリ内のファイルを読み取って確認してください。

• docs/agents/project.md、docs/agents/issue-tracker.md、docs/agents/triage-labels.md — 存在して内容が記入されているか、または欠落しているか
• docs/agents/project.md 内の ## Team セクション — 存在して内容が記入されているか、または未記入か
• CLAUDE.md / AGENTS.md に ## Agent skills セクションがあるか（どちらのファイルが存在するかも記録します）
• スキルセットが必要とするシードファイル：docs/specs/INDEX.md、用語集（CONTEXT.md または CONTEXT-MAP.md）
• .gitignore に .skills/ と .worktrees/ があるか

確認した内容に応じて、次のように進めます。

• すでに設定済み（一部または完全に設定済み） — これは再構築ではなく、不足箇所を補う作業です。存在するものと欠落または古くなっているものを正確に列挙し、その要約をユーザーに提示して、不足箇所のみを補うか尋ねます。出力が欠落しているセクション、またはユーザーが明示的に変更を求めたセクションのみ、ステップ2で進めます。すでに記入されている内容は変更しません（ステップ4の加筆のみのルール）。
• 未設定 — ステップ2のユーザー主導の流れに進みます。Git リモートや接続済み MCP サーバーからトラッカーを推測したり、ユーザーが選ぶべき項目を自動検出したりしてはいけません。何をどのように設定するか、一度に一つずつユーザーに尋ねます。

後のステップで提案を事前入力するために、リポジトリ内のマニフェスト（ロックファイル、package.json のスクリプト、Cargo.toml、pyproject.toml、Makefile、テスト設定など）を読むことはできます。ただし、リポジトリ内のファイルを読むこととサービスを調べることは別です。また、事前入力した提案をユーザーに代わって決定することはありません。

完了条件： リポジトリを設定済み／一部設定済み／未設定に分類し、不足箇所を列挙して、その要約をユーザーに提示していること。

2. セクションごとに一つずつ決める

以下の10項目（A～J。Iは任意のプロジェクト文書）を、必ず一度に一つずつ進めます。各項目について、2～3文で説明します（何であるか、どのスキルが使うか、選択によって何が変わるか）。一行で推奨案とその理由を述べ、次へ進む前にユーザーの回答を待ちます。すべての項目をまとめて提示してはいけません。ユーザーはこれらの概念を初めて知るものとして説明してください。

A. Issue トラッカー

説明：課題を読み書きするスキル（triage、file-issues、タスクを公開する場合の write-plan、release）は、課題がどこにあり、どのコマンドが課題に関わるかを把握する必要があります。

選択肢：

• github — gh CLI を介したリポジトリの課題
• gitlab — glab CLI を介したリポジトリの課題
• linear — Linear の課題。接続済みの Linear MCP サーバー（推奨）または Linear GraphQL API を使用します。コードホストではなく Linear で作業を追跡しているチーム向けです
• local — .scratch/<feature>/ 配下の Markdown ファイル。各ファイルには Status: 行が含まれます。個人で使うリポジトリやリモートのないリポジトリに適しています
• other — ユーザーがワークフローを段落で説明し、それを自由記述として記録します

推奨する選択肢は、リポジトリのローカル Git リモートに基づくものだけにしてください。GitHub のリモートなら github、GitLab のリモートなら gitlab、リモートがなければ local を推奨し、必ずユーザーが変更できるようにしてください。トラッカーを推測するために、サービスやその認証を調べてはいけません。Linear は独立したサービスであり、git remote には表示されないため、選択肢として提示してください。チームが Linear を使っているとユーザーが言った場合は、コードホストが GitHub／GitLab であっても、必ず Linear を選んでください。

追加の質問（github／gitlab のみ）：外部からのプルリクエストをリクエスト窓口として扱いますか？ 説明：オープンソースのリポジトリでは、機能リクエストが PR として届くことがよくあります。PR はコードが添付された課題です。「はい」の場合、triage は外部 PR を同じキューと状態遷移に取り込みます。デフォルトは「いいえ」です。linear／local／other の場合、この質問は省略してください。Linear を使うチームでは、リクエストは Linear の課題として届き、PR はリンクされたコードホストに残り、トリアージのキューには入りません。

完了条件： トラッカーの選択と、PR をリクエスト窓口として扱うかどうかが確定していること。

B. トリアージのラベル対応付け

説明：triage は課題を標準的な役割間で移動しますが、重複を作成しないよう、このリポジトリで実際に使われているラベル文字列を適用する必要があります。

標準的な役割は、5 つの状態と 2 つのカテゴリです。

役割	意味
needs-triage	評価待ち
needs-info	報告者からの情報待ち
ready-for-agent	仕様が完全で、エージェントが事前情報なしで着手できる
ready-for-human	人間による判断またはアクセスが必要
wontfix	対応しない
bug	不具合がある
enhancement	新機能または改善

トラッカーに既存のラベルがあれば、各役割と並べて一覧表示し、対応付けを提案してください（デフォルトでは、各役割の文字列は役割名と同じです）。ユーザーに対応付けを確認してもらってください。対応付けられたラベルがトラッカーにまだない場合は、作成を提案してください。ただし、ユーザーの明示的な同意がある場合に限ります。local トラッカーでは、役割名自体が語彙となるため、デフォルトのままで問題ありません。linear の場合は、まずチームの既存のワークフロー状態とラベルを一覧表示し（MCP サーバーまたは API を使用）、状態の役割を適切な Linear のワークフロー状態に対応付けてください（例：ready-for-agent → 「Todo」／「Ready」状態、wontfix → 「Canceled」状態）。次に、カテゴリの役割（bug／enhancement）を Linear のラベルに対応付けてください。

完了条件： すべての標準的な役割が、確認済みのラベル文字列に対応付けられていること。

C. コマンドの確認

説明：tdd、verify、execute-plan、release は、いずれもこのリポジトリの検証コマンドを実行します。推測ではなく、正確なコマンドを指定する必要があります。

検出した内容をあらかじめ入力したうえで、各コマンドを確認してください。対象は、型チェック、lint、ユニットテスト、e2e／スモークテスト、および単一テストファイルの実行パターン（1 つのテストファイルを実行するコマンド形式であり、tdd が使用する短い実行サイクルの中核となるもの）です。

完了条件： 各コマンドがユーザーによって確認済みであること（または「なし」と明示されていること）。

D. テストのアノテーション規約

説明：各テストには、対象とする要件 ID が記載されます。また、trace チェックはテスト内でこれらの ID を grep するため、規約は grep で検出でき、リポジトリのフレームワークに適合している必要があります。

テストレイヤーごとに、検出したフレームワークに基づいて規約を提案してください（例：{ tag: ['@CODE-N.M'] } のような e2e タグ、ユニットテストのアノテーションまたはテスト名への ID の記載、コンパイル言語での /// REQ: CODE-N.M ドキュメントコメント）。レイヤーごとに 1 つの規約を確認してください。

完了条件： リポジトリ内のすべてのテストレイヤーについて、ID の規約が確認済みであること。

E. リリース手順

説明：release スキルは、プロジェクト固有のコマンド（ビルド、バンドル、署名、公開）を順番どおりに実行します。手順を独自に変更することはありません。

見つかった情報（ビルドスクリプト、パッケージ設定）をもとに順序付きリストを作成し、確認してください。スモークチェック用のコマンドがある場合は、それも含めてください。

完了条件： リリース手順が確認されていること（ビルドのないライブラリの場合は、空のリストでもかまいません）。

F. ドキュメントの構成

説明：仕様策定スキルと情報探索スキルは、docs/specs/、docs/adr/、ドメイン用語集を参照するため、その構成を把握する必要があります。

以下を確認してください：

• 仕様書は docs/specs/、ADR は docs/adr/ に配置します（存在しない場合はディレクトリを作成してください）。
• 用語集の構成：単一コンテキスト（ルートに CONTEXT.md を1つ配置。ほとんどのリポジトリはこちら）または複数コンテキスト（ルートの CONTEXT-MAP.md から、コンテキストごとの CONTEXT.md を参照。通常はモノレポはこちら）

完了条件： 構成が確認されていること。

G. プロジェクトの方針

説明：プロジェクトには、提供目標（成果物に求められる堅牢性）とライフサイクルの段階（プロジェクトがどの段階にあるか）という、常に把握しておくべき2つの事実があります。brainstorm と grilling はこれらを参照して、手続きの程度を適切に調整します（プロトタイプではデータ移行や非推奨化を深く検討する必要はありませんが、リリース済みで拡大中のシステムでは重要です）。また、interpret はこれらを再利用し、同じ質問を繰り返さないようにします。これらは docs/agents/project.md に記載され、プロジェクトの段階が進むたびにユーザーが該当する2行を直接編集します。

リポジトリの状況をもとに、両方を事前入力して確認してください。推測で作成してはいけません。

• 提供目標 — Production / MVP / Prototype / Research / Learning。リポジトリから推奨してください（公開済みパッケージやリリースワークフローがある場合は Production、何もない新規の試作リポジトリなら Prototype）。不明な場合は MVP を既定値とします。
• ライフサイクルの段階 — Idea / Early development / Active development / Released / Scaling / Maintenance。Git の情報をもとに推奨してください（タグやリリース履歴がある場合は Released、コミットが少ない新しいリポジトリなら Early development）。不明な場合は Early development を既定値とします。

完了条件： 両方の方針値をユーザーが確認していること。

H. チーム

説明：チームの構成、つまりメンバーや役割の一覧と任意の CODEOWNERS 所有権メモは、brainstorm、grilling、write-plan、execute-plan、code-review、finish-branch、handoff で常に参照されるコンテキストです。これらのスキルは、記載された docs/agents/project.md の ## Team のルールに従い、規模（Solo / Small / Multi）ごとにコラボレーションの進め方を調整します。規模を誤ると、調整も誤ります（1人で運用するリポジトリに実在しないレビュアーを追加したり、複数人のリポジトリで所有権を明確にしなかったりします）。これはプロジェクトの方針と同じ種類の情報であり、提供目標やライフサイクルの段階とは別のものです。

判断 H を実行するときは、このファイルと同じ場所にある team-inference.md を読み、その指示に厳密に従ってください — 使用するのはローカルの Git / CODEOWNERS / AUTHORS / CONTRIBUTORS / パッケージマニフェストのみです。推論してから確認してください。

ユーザーへの説明（簡潔に）：ローカルのメタデータをもとにメンバー一覧の草案を提示します。名前や役割を編集するか、人数形式（N × Role）に切り替えてください。確認されるまで書き込みは行われません。

推奨事項：プレースホルダーの役割を、分かる範囲で実際の役職に置き換えたうえで、草案を承認してください。プライバシーを重視する場合は人数形式を使用してください。ワークフロー規模の上書きは、メンバー一覧が実際のリポジトリの運用方法と一致しない場合にのみ設定してください（例：1人のエージェントユーザーが運用するモノレポ）。

想定	実際
「gh api からコラボレーターを取得する」	ローカルのメタデータのみを使用します — コラボレーター API は使用しません
「コミット数からテックリードが分かる」	役職を推測で作成してはいけません。ユーザーが役割を変更するまでは Contributor を既定値とします
「Git の履歴が空なので、開発者は1人だと推測する」	空の草案を提示して質問してください。名前を推測で作成してはいけません
「草案を書いて、後で修正する」	確認が必要です。この実行で明示的な確認を得るまで、チーム情報を書き込んではいけません

完了条件： ユーザーがメンバー一覧（名前および／または人数形式）、任意の所有権メモ、任意の規模の上書きを確認していること。または、チームについて明示的に保留していること（未解決のままにします）。

I. プロジェクトドキュメントレイヤー（任意 — デフォルトは「いいえ」）

説明：大規模なプロジェクトや長期にわたるプロジェクトでは、機能ワークフローの上に、任意のリポジトリレベルのレイヤーを追加できます。establish-project で作成する、プロダクトビジョン（docs/product/vision.md）、ID 付きのアーキテクチャ不変条件の基軸（docs/architecture/）、エンジニアリングガイドライン（docs/product/guidelines.md）です。これらが存在する場合、brainstorm、write-design、write-plan、execute-plan、code-review から参照されます。存在しない場合は、何も変わりません。小規模なリポジトリでは追加を見送りましょう。後から /establish-project で追加できます。

推奨：大規模な複数機能プロジェクトでない限り、いいえ。

はいの場合：Step 4 の項目として記録します（3 つのドキュメントと Agent-skills の行を用意します）。docs/agents/project.md または既存の CLAUDE.md／AGENTS.md にエンジニアリングガイドラインがすでに記載されている場合は、docs/product/guidelines.md への移行を提案し、元の場所には参照先を残します。

完了条件： このレイヤーを採用するか、採用しないことが決まっている。

J. デフォルトの PR ベースブランチ

説明：prepare-change は、ベース解決の優先順位で 3 番目にあたる値として、docs/agents/project.md の Default PR base: を読み取ります。明示的に指定された実行時のベースブランチ、既存の PR にすでに記録されているベースブランチの次です。これにより、トランクブランチが記録されていれば、確認を求めなくなります。finish-branch は引き続き独自にトポロジーを検出します（Step 2）。Option 1 では、セッション用の PR パッケージに Base: が記録されている場合、その値を検出結果より優先します。このフィールドは prepare-change の解決に使われるものであり、finish-branch が直接利用する値ではありません。

dev、staging、main、およびリポジトリ内のローカルブランチ一覧は、あくまで候補として提示します。値は事前に選択されません。ブランチ名は必ずユーザー自身が指定します。

推奨：リポジトリで実際にトランクとして使われているブランチ（通常は main）。理由：特に指示がない限り、prepare-change と finish-branch がすでにこのブランチを想定しているためです。

選択を見送る場合：ユーザーが選択を見送った場合は、値を一切書き込まず、このフィールドの Step 4 の項目をスキップします。その場合、prepare-change は実行のたびにベースブランチを確認します。これにより、ARCH-2 に従って、このフィールドが真に任意のままになります。

完了条件： ユーザーが値を確認したか、明示的に選択を見送り、値を書き込まないことが決まっている。

3. 下書きの作成と確認

何かを書き込む前に、次の内容をユーザーに提示します。

• 3 つの docs/agents/*.md ファイルの内容（Decision H が確定している場合は、確定した ## Team を含めます）
• CLAUDE.md／AGENTS.md に追加する ## Agent skills ブロック

ユーザーが編集できるようにします。完了条件： ユーザーが下書きを承認している。

4. 書き込み

既存ファイルはそのまま編集し、決して上書きしないという追加ルールがあります。 対象ファイルがすでに存在する場合は、内容を統合し、ユーザーが記述した内容をすべて保持します。

1. templates/agents/project.md、templates/agents/issue-tracker.md、templates/agents/triage-labels.md をもとに、docs/agents/project.md、docs/agents/issue-tracker.md、docs/agents/triage-labels.md を作成します。issue-tracker ファイルには、選択されたトラッカーの操作セクションだけを残し、PR サーフェスの回答を記録します。

2. docs/specs/INDEX.md が存在しない場合は、templates/specs-INDEX.md をもとに作成します。

3. 用語集がない場合は、templates/CONTEXT.mdからCONTEXT.mdを作成します（ユーザーの回答に応じて、複数のコンテキストがある場合はCONTEXT-MAP.mdを作成します）。

4. docs/agents/project.mdのProject postureセクションに、確認済みの提供意図とライフサイクル段階（Decision G）を入力します。テンプレートのプレースホルダーを置き換えて2行にします。（追加方式：セクションにすでに実際の値がある場合は、ユーザーが変更した内容だけを更新します。）

5. 確認済みのDecision Hの内容（メンバー構成、担当に関する注記、任意のバンド上書き）を使って**## Team**を入力し、templates/agents/project.mdのテンプレート形式に統合します。Teamセクションのうち、確認済みの項目だけを置き換えます。他のセクションは上書きしないでください。ユーザーがTeamの入力を保留した場合は、テンプレートのプレースホルダーを残すか、入力漏れを補完する実行を行うまで省略します。

6. プロジェクトドキュメント層を有効にすることが選択されている場合（Decision I）： templates/product-vision.md、templates/architecture-INDEX.md、templates/product-guidelines.mdを基に、docs/product/vision.md、docs/architecture/INDEX.md、docs/product/guidelines.mdを作成します（上記のルールに従い、既存の内容を追加します）。移行する場合は、既存のエンジニアリングルールをdocs/product/guidelines.mdに移し、docs/agents/project.mdに参照先を記載します。この層を導入しない場合は、この手順を省略し、これらのファイルは作成しません。

7. ## Agent skillsブロックを追加します。これは正規ファイル1つだけに記載します。2つ目のファイルを作る場合は、ブロックのコピーではなく、簡潔な参照先のみを記載します。

   • CLAUDE.mdもAGENTS.mdも存在しない場合（デフォルト）：AGENTS.mdを正規ファイルとして作成し、ブロックを記載します。AGENTS.mdを参照する短いCLAUDE.mdを作成し、その本文全体を参照先の記載だけにします。これにより、Claude Codeがネイティブのファイル名で指示を見つけられ、内容の重複も避けられます。どちらを作成するか尋ねる必要はありません。この方法で両方に対応できます。
   • **どちらか一方だけが存在する場合：**そのファイルを正規ファイルとして、ブロックを追加または更新します。正規ファイルがAGENTS.mdで、Claude Codeも対象である場合は、CLAUDE.mdの参照先も追加します。正規ファイルがCLAUDE.mdの場合は、そのまま正規ファイルとして使います。参照先ファイルに変更したり、競合するAGENTS.mdを作成したりしないでください。
   • **両方が存在する場合：**実際のエージェント指示がすでに記載されている方にブロックを記載します。もう一方に実質的な内容がなければ、参照先だけを記載します。ブロックを両方に記載しないでください。
   • 正規ファイルにすでに## Agent skillsセクションがある場合は、その場で更新します。重複するセクションを追加したり、周辺のセクションを変更したりしないでください。

   作成するCLAUDE.mdの参照先は次のとおりです。

   # CLAUDE.md
   
   The canonical agent instructions for this repo live in **[AGENTS.md](AGENTS.md)** —
   read it first. It applies to Claude too; this file exists only so Claude Code
   finds it by its native name.
   

ブロック（Decision IがYesの場合に限り、プロジェクトドキュメント層の箇条書きを含めます）：

## Agent skills

This repo is configured for a spec-driven skill set.

- Feature flow: `brainstorm` → `write-requirements` → `write-design` →
  `write-plan` → `execute-plan`
- Bug on-ramp: `debug` (root cause first, then a guarded fix)
- Capture a conversation/spec/idea into tracker issues: `/file-issues` (user-run)
- Incoming issues and PRs: `/triage` (user-run)
- Traceability check: the `trace` skill — run by `verify` and `release`;
  keep it clean
- Project docs (layer enabled): `/establish-project` maintains
  `docs/product/vision.md`, the `docs/architecture/` invariant spine, and
  `docs/product/guidelines.md`; the feature skills consult them

Repo config the skills read:

- Verify commands, test annotations, release steps: `docs/agents/project.md`
- Team composition (roster, ownership notes, workflow band): `docs/agents/project.md` (`## Team`)
- Issue tracker operations: `docs/agents/issue-tracker.md`
- Triage label mapping: `docs/agents/triage-labels.md`

8. ローカルの作業ディレクトリがGitの追跡対象外になっていることを確認します。スキルの一時ファイル（execute-planの台帳と概要、および仕様スキルが書き込むスキャン／レビューのダイジェスト）は.skills/に、分離されたワークスペースは.worktrees/に保存されます。どちらもバージョン管理の対象にしてはいけません。各パターンについて冪等に、grep -qxF '.skills/' .gitignore 2>/dev/null || printf '.skills/\n' >> .gitignoreを実行します（.worktrees/についても同様です）。その後、.gitignoreをステージします。（行の有無を確認します。git check-ignoreではありません。末尾にスラッシュのあるパターンは既存のディレクトリにしか一致しないため、ディレクトリがまだ存在しない状態でcheck-ignoreを使うと、行が再追加されます。）
9. Decision J（デフォルトのPRベース）が確認済みの場合は、上記の追加ルールに従って、docs/agents/project.mdのProject postureセクションに- **Default PR base:** \`を追加します。既存のユーザー設定値は上書きせず、統合します。Decision Jを選択しなかった場合は何も記載しません。値を省略し、prepare-change`が実行ごとに尋ねるようにします。

**完了条件：**すべてのファイルが書き込まれ、.skills/と.worktrees/がGitの追跡対象外になっており、git statusに想定された追加・編集だけが表示されること。

5. セッション開始フックを提案する

このスキルセットは、リポジトリにほかのものをインストールしません。リンターも、CI の手順も、git フックもありません。任意の提案が 2 つ残っています。1 つはスキル使用ゲートを有効に保ち、もう 1 つはスキルに最新のライブラリ情報を提供します。

セッション開始フック。 このスキルセットがプラグインのフックに対応していない環境にインストールされた場合は、ゲートが /clear やコンパクション後も維持されるよう、SessionStart フック（マッチャー startup|clear|compact）の追加を提案します。フックはリポジトリ内にベンダーとして同梱してください。リポジトリ外のパスは決して参照しないでください。 絶対パス（例：スキルセット自体の作業コピーへのパス）を .claude/settings.json にコミットすると、ほかのマシンや CI では、あるいはそのコピーが移動した場合に動作しなくなります。代わりに、次のようにします。

• templates/session-start.sh をリポジトリ内の .claude/hooks/session-start.sh にコピーし、chmod +x を実行します。依存関係がない（単純な cat のみ）ため、ツールチェーンにかかわらずどのプロジェクトでも動作します。
• 絶対パスではなく、プロジェクトディレクトリ変数を使って .claude/settings.json から参照します。

  { "hooks": { "SessionStart": [ { "matcher": "startup|clear|compact",
    "hooks": [ { "type": "command",
      "command": "\"$CLAUDE_PROJECT_DIR/.claude/hooks/session-start.sh\"" } ] } ] } }
  

• 既存の SessionStart ブロックがある場合は、ほかのフックを上書きせず、追加する形で統合します。

Context7 MCP — 最新のライブラリドキュメント用。 複数のスキルはサードパーティ製ライブラリについて推論します。research はライブラリの動作が質問の要点となる場合に、write-design は再利用の段階が新しい依存関係に達した場合に使用されます。トレーニング時の知識だけに頼ると、エージェントが数か月前のバージョンや API を引用する可能性があります。ユーザーには、ソースから最新かつバージョン固有のドキュメントを提供する Context7 MCP サーバー のインストールを勧めてください。ライブラリ関連のスキルは、Context7 が利用可能な場合は優先して使用し、利用できない場合は公式ドキュメントを取得する、と説明してください。これはエージェント環境のツールであり、リポジトリ内のファイルではありません。Claude Code では、プロジェクトの .mcp.json（またはユーザーの MCP 設定）に追加します。ほかのハーネス（Kimi、Codex、…）では、そのハーネスの MCP 設定に追加します。ユーザーが導入に同意した場合は、スキルが参照できるよう、docs/agents/project.md に記録します（「Library docs: Context7 MCP (preferred)」という 1 行のメモ）。これはあくまで推奨です。セットアップを妨げてはならず、自分でインストールや認証を試みてはいけません。

完了条件： セッション開始フックと Context7 MCP の推奨の両方について、明確な「はい／いいえ」を確認し、「はい」の場合は実装されていること（フックをインストールする、または docs/agents/project.md に Context7 のメモを記載する）。

6. 設定が実際に機能することを証明する — GATE

ユーザーが確認したことと、このプロジェクトで機能することは同じではありません。コマンドは検出した内容をもとに事前入力されていますが、マニフェストのパスが間違っていたり、スクリプトがなかったり、ツールがインストールされていなかったりすると、数週間後に tdd、verify、または release の実行中に問題が発生します。コンテキストを把握している今、問題がないことを証明してください。これは、たった今書いた設定に verify スキルの規律を適用することです。コマンドを実行し、出力を読み、その出力を信頼してください。設定を信頼するのではありません。

設定された各 verify コマンドをあらためて実行し、結果を分類してください。重要なのは、配線と内容の違いです。

• 配線の失敗 — コマンドを記述どおりに実行できませんでした。「command not found」／終了コード 127、「missing script」、「no such file or directory」、不正な --manifest-path や不明なフラグ、未インストールのツールなどです。これは修正必須の設定バグです。再検出し、docs/agents/project.md を修正して、解消するまで再実行してください。コマンドの配線に問題がある限り、セットアップは完了ではありません。
• 内容の失敗 — ツールは正しく実行されたものの、問題（型エラー、lint の警告、失敗するテスト）を報告しました。コマンドの配線は正しく、リポジトリに既存の問題があります。これらをユーザーに報告してください。セットアップの妨げにはなりません。
• 成功 — 正しく配線され、問題なく完了しました。

コストに配慮し、配線を証明するためにスイート全体を実行しないでください。

• 型チェックと lint：全体を実行します（上限を設けてください）。
• Unit／e2e ランナー：設定を低コストで解決できることを証明します。project.md に記載された単一テストファイルのパターンを既存のテストファイル 1 つに対して実行するか、ランナーの collect-only／list モードを使ってください。セットアップ中に e2e を全件実行してはいけません。全件実行は後でユーザーが行う必要があることを明記してください。
• Trace check：実行し、問題のない検出結果であることを確認します（必須サブスキル：trace を使用してください）。要件がゼロであることも、問題のない状態です。このチェックは docs/specs/ とテストの glob に対して grep／git を使うため、インストールは不要です。検索対象のテスト glob がこのリポジトリの構成に一致しない場合は、正しいものを今すぐ docs/agents/project.md に記録してください。
• セッション開始フックをインストールした場合は、.claude/hooks/session-start.sh を実行し、有効な JSON が 1 行出力されることを確認してください。
• トラッカーがリモートサービス（github／gitlab／linear）の場合は、読み取り専用の呼び出しを1 回行って、接続可能で認証済みであることを証明してください。gh issue list／glab issue list、または Linear なら MCP の list 呼び出し 1 回（あるいは最小限の issues GraphQL クエリ）を使います。これはユーザーがすでに選択したトラッカーを検証するものであり、セットアップ時の検出ではありません。Step 1 で禁止されている検出とは異なります。選択は済んでおり、この呼び出しでは正常に動作することだけを証明します。CLI がない、セッションが未認証、または MCP サーバーが切断されているか未認証の場合は、配線の失敗です。確認しなければ、数週間後に triage が失敗するまで問題が隠れたままになります。local と other では、接続確認は不要です。

簡潔な表を報告してください。各コマンド → 配線済みか → 成功／失敗／既存の問題。

完了条件： 設定されたすべてのコマンドについて、配線済みであることが証明され（配線の失敗が残っていないこと）、trace check が問題なく実行され、フック（インストールされている場合）が動作し、設定されたトラッカーが読み取り専用の呼び出しに応答し、内容に関する失敗があればユーザーに報告されていること。

7. 完了

セットアップが完了したこと、どのスキルがこの設定を読み込むようになったか、verify の表に配線済みの項目と既存の問題が示されていることをユーザーに伝えてください。また、docs/agents/*.md は後から直接編集でき、トラッカーの切り替えや最初からやり直す場合にのみ、このウィザードを再実行すればよいことも伝えてください。