---
name: setup
model: inherit
description: "GUIDE_01 に従い，プロジェクトの立ち上げを対話的に進める．各フェーズでユーザーの確認を挟む．"
argument-hint: "<プロジェクト名>"
---

あなたはプロジェクト立ち上げのファシリテーターです．
GUIDE_01（プロジェクト立ち上げフロー）を読み，各フェーズのルールを理解した上で以下の手順を実行してください．
`gh` CLI で行う GitHub リポジトリ設定のコマンドと，`.github/dependabot.yml` の生成規則は本スキルの `reference.md`（`.claude/skills/setup/reference.md`）を参照する．

## 基本ルール

- 各フェーズの成果物をユーザーが承認してから次のフェーズに進むこと
- ユーザーが「今日はここまで」と言った場合，CLAUDE.md の進捗（最新 1 行）と `docs/PROGRESS.md`（追記）を更新して中断する
- ドキュメントの書式・命名は `.claude/rules/markdown-style.md`・`.claude/rules/docs-naming.md` に従って作成する（該当ファイル編集時に自動ロードされる）
- 成果物のドラフトを提示し，ユーザーの修正指示を反映してからファイルに書き出す
- フォルダは成果物を実際に書き出すときにのみ作成する．空のカテゴリフォルダを先回りで作らない

## 立ち上げ中の Git 運用 (Git During Setup)

立ち上げ作業は専用ブランチ `chore/project-setup` の上で行い，**各フェーズの成果物を書き出してユーザーが承認したら，その場でコミットする**（フェーズごとに 1 コミット）．手順・コミットメッセージの対応表は本スキルの `reference.md`（`.claude/skills/setup/reference.md`）「フェーズごとのコミット」に従う．

- 本スキルは CLAUDE.md「Git 運用」の「`/commit` 自発実行禁止」に対する**ユーザー承認済みの例外**である（`/auto-refactor`・`/auto-audit` と同格）．例外が認められるのは `chore/project-setup` ブランチへのコミットに限る
- **`git push`・PR 作成・マージ・`main` への直接コミットは一切行わない**．`main` への取り込みは全フェーズ完了後にユーザーが `/commit push`（または `/commit merge`）で行う
- ブランチは最初のコミットを作る直前に `main` から作成する．既に `chore/project-setup` にいる場合（再開時）はそのまま使い続ける
- コミット履歴がそのままフェーズの進捗になるため，中断・再開しても「どこまで終わったか」が git から辿れる（`CLAUDE.md` の進捗欄・`docs/PROGRESS.md` の更新はそのフェーズのコミットに含める）

## 前提確認 (Pre-check)

1. CLAUDE.md がテンプレート初期状態（タイトルが `# プロジェクト名` のまま）か確認する
2. **初期状態の場合（新規プロジェクト立ち上げ）:**
   - プロジェクト名を確定する（引数 `$ARGUMENTS` があればそれを使用，なければユーザーに確認）
   - プロジェクト概要（1〜2 行）をユーザーに確認する
   - CLAUDE.md の以下を書き換える:
     - 1 行目の `# プロジェクト名` → `# {確定したプロジェクト名}`
     - 3 行目の `<!-- プロジェクトの概要を 1〜2 行で記述する -->` → 概要テキスト
3. CLAUDE.md の「開発進捗」と `docs/PROGRESS.md` を確認し，どのフェーズから再開するか判断する
4. 初回の場合はフェーズ 1 から開始する

## 開発モードの選択 (Development Mode)

新規立ち上げ時（Pre-check で初期状態だった場合），フェーズ 1 に入る前に開発モードを 1 度だけ確定する．既に `.claude/project-mode` がある場合（再開時）はこのステップを飛ばす．

ユーザーに次を確認する:

「**このプロジェクトの開発モードを選んでください．**

- **solo（個人開発）**: 1 人で開発する．進捗は `CLAUDE.md` の進捗欄＋ `docs/PROGRESS.md` で追う．
- **team（チーム開発）**: 複数人が Claude Code で開発する．進捗・タスクは GitHub Issues と git 履歴で追い，直列運用・条件付きセルフマージ等のチームルール（GUIDE_03）を適用する．

どちらにしますか？（後から `/set-mode <solo|team>` で切り替えられます）」

確定したら以下を行う:

1. `.claude/project-mode` にモード（`solo` または `team` のいずれか 1 語）を書き出す．
2. **solo の場合**: チーム層ファイルが clone で配置されていれば削除し，solo プロジェクトを clean に保つ:
   - `docs/01_GUIDE/GUIDE_03_チーム開発ルール.md`
   - `.claude/hooks/check_sync.sh`
   - ※ `task-create` / `task-start` / `task-handoff` の各 skill は共通層（solo でも Issue ベースのタスク管理に使える）のため削除しない．
   - ※ `.claude/settings.json` はそのまま（solo でも `restrict_repo_access.py` を使う）．SessionStart(check_sync) の配線は追加しない．
3. **team の場合**: 上記チーム層ファイルを残す．加えて:
   - `.claude/settings.json` に SessionStart フックを追記して `check_sync.sh` を配線する（既存の PreToolUse ブロックは保持する）:
     ```json
     "SessionStart": [
       {
         "hooks": [
           { "type": "command", "command": "bash .claude/hooks/check_sync.sh", "timeout": 10 }
         ]
       }
     ]
     ```
   - `.gitignore` に `.claude/settings.local.json` が無ければ追記する（個人設定用．GUIDE_03）．
   - CLAUDE.md のチーム化は Phase 7 で行う（この時点ではまだ立ち上げ中で Issue/repo が無いため，進捗欄は setup 再開用にそのまま使う）．

### 進捗記録（立ち上げ中）

立ち上げ中は repo/Issue がまだ無いため，**モードに関わらず** setup 再開のための進捗は `CLAUDE.md` の進捗欄（最新 1 行）＋ `docs/PROGRESS.md` に記録する．team モードでの「進捗を Issue で追う」への切り替えは Phase 7（実装開始）以降に適用する．

## フェーズ 1〜6: 各フェーズの実行

GUIDE_01 に定義された各フェーズを順番に実行する．
各フェーズで以下の手順を繰り返す:

1. GUIDE_01 の該当フェーズを参照し，目的・成果物・役割分担を確認する
2. ユーザーとの対話で情報を収集する
3. 成果物のドラフトを作成し，ユーザーに提示する
4. 承認を得てから GUIDE_01 に記載された保存先に書き出す
5. 書き出した成果物をコミットする（前述「立ち上げ中の Git 運用」・`reference.md`「フェーズごとのコミット」．push・PR は行わない）

### 台詞テンプレート

「**フェーズ {N}（{フェーズ名}）のドラフトです．**

{ドラフト内容}

修正点があれば指示してください．OKであれば {保存先} に保存し，`chore/project-setup` にコミットして次のフェーズに進みます．」

### フォルダ作成の注意

成果物を書き出すフォルダのみ作成する．`.claude/rules/docs-naming.md` のカテゴリ表は「あり得るカテゴリの一覧」であり，立ち上げ時に全カテゴリのフォルダを scaffold するものではない．GUIDE_01 の立ち上げフェーズで成果物が発生するのは `02_ENV / 03_PLAN / 04_SPEC` と `.claude/rules/`（規約整備フェーズ）のみ．`05_TECH/`（技術設計）と `06_TEST/`（テスト）は立ち上げ時には成果物が無いため，空フォルダを作らない（実装フェーズで必要になった時点で作成する）．

### フェーズ 3（環境構築）の注意

外部サービスの設定（アカウント作成，コンソール操作等）はユーザー自身が行う．手順書に記載するが，AI が実行しないこと．
**例外**として，`gh` CLI で操作できる GitHub リポジトリ設定は AI が実行する．
手順書を書き出した後は，それ以外の手順を実際に実行して環境を構築する（後述「環境構築の実行」．ツール導入は都度承認を得る）．

### GitHub リポジトリのセキュリティ設定 (GitHub Repository Security Settings)

Dependabot alerts（"Vulnerabilities"）と Dependabot security updates はリポジトリごとに既定で OFF のため，モード（solo / team）に関わらず AI が `gh api` で有効化する．コマンド・検証・トラブル対応は本スキルの `reference.md`（`.claude/skills/setup/reference.md`）「GitHub リポジトリのセキュリティ設定」に従う．

- `ENV_03_管理者用環境構築手順.md` のドラフトには，GitHub リポジトリ作成の直後の手順として `reference.md` の有効化・検証コマンドを必ず転記する（`/setup` 後にリポジトリを作った場合に管理者が単体で実行できるようにするため）
- ENV_03 を書き出したら，その場で `reference.md` の手順を 1 度実行する．リモート未作成で実行できなければ Phase 7 で再試行する

### 依存バージョン更新の設定 (Dependabot Version Updates)

上記の脆弱性検出とは別に，依存パッケージを定期的に最新化する PR を Dependabot に作らせるため，フェーズ 3 で `.github/dependabot.yml` を**ユーザーに選択を聞かずに必ず生成する**（`.gitignore` 等と同じ「設定ファイルの生成」の一部として扱う）．

- フェーズ 2 で確定した技術スタック（`ENV_01_技術スタック.md`）から対象エコシステムを決め，`reference.md`「依存バージョン更新の設定」の対応表と雛形に従って生成する
- 生成内容（対象エコシステム・更新頻度・グループ化）は他の成果物と同様にドラフトとしてユーザーに提示し，承認を得てから書き出す（「作るかどうか」は聞かず，「内容」だけを確認する）
- マニフェストがまだ存在しない場合（立ち上げ時点でコードが無い）でも，スタックが確定していれば生成してよい．Dependabot はマニフェストが置かれた時点から動き始める

### 環境構築の実行 (Executing the Environment Setup)

`ENV_02_環境構築手順.md`・`ENV_03_管理者用環境構築手順.md` を書き出したら，**手順書を渡して終わりにせず，その手順に従って実際にこの環境を構築する**．未検証の手順書は誤り・前提の抜けを含みやすく，最初に詰まるのはその場のユーザーであるため．実行の分類（そのまま実行する／承認を取る／ユーザーに依頼する）と進め方は `reference.md`「環境構築の実行」に従う．

- リポジトリ内で完結する操作（プロジェクト初期化・依存インストール・設定ファイル生成・ビルドや起動の疎通確認・`gh` でのリポジトリ設定）はそのまま実行する
- ツール導入（SDK・ランタイム・CLI のインストール，`docker build`，dev container の起動）は**実行するコマンドを提示して承認を得てから**実行する．OS・パッケージマネージャ・バージョン・入る場所（システム全体かプロジェクト内か）を明示する
- 外部サービスのコンソール操作・アカウント作成・対話ログイン（`gh auth login` 等）・クレデンシャルの発行はユーザーに依頼する（`! gh auth login` のように `!` を付けてその場で実行できることを案内する）
- 実行して分かった手順書の誤り・不足・OS 依存の差異は `ENV_02`／`ENV_03` に反映してからコミットする．解決できなかった手順は「※ 未検証」と明記して残す
- 確定した起動・テスト・lint・ビルドのコマンドは `ENV_04_開発コマンド.md` に書き出す（GUIDE_01「環境構築」）
- 生成物（`node_modules/`・ビルド出力等）を作る前に `.gitignore` を整備する

### 検証プロファイルの作成（任意） (Verify Profile)

技術スタックと開発コマンドが固まった後（フェーズ 3 の最後）に，Claude による動作確認を使うかをユーザーに 1 度だけ確認する．**既定は「作らない」**であり，作らなくても `/implement` の流れは従来どおり（Phase 1b はスキップされ，動作確認は人間が行う）．

「**Claude がローカルでアプリを操作して動作確認する仕組みを用意しますか？（任意）**

検証プロファイル（`.claude/verify-profile.md`）を用意すると，`/implement` の Phase 1b と `/verify` で Claude がエッジケース等を先に確認し，あなたが見る範囲を「デザイン・操作感・実機の挙動」等に絞れます（人間の確認は無くなりません）．
別途，シナリオを実行するランナー（起動・実行・集計・後始末）をプロジェクト側に用意する必要があります．

- **今は作らない**（既定）— 後から `/verify` の案内に従って用意できます
- **作る** — 雛形を埋めながら一緒に作ります」

「作る」を選んだ場合:

1. `.claude/skills/verify/profile-template.md` を `.claude/verify-profile.md` にコピーする
2. 雛形の各節を，確定した技術スタック・開発コマンドに合わせてドラフトし，他の成果物と同様にユーザーの承認を得てから書き出す．埋められない項目（ランナー未整備のため実行コマンドが未定等）は空欄にせず「未定（ランナー整備後に記入）」と明記する
   - 「検証対象の環境」は**ローカルのみ**でドラフトする．staging 等を許可するかは Claude が判断せずユーザーに確認し，許可する場合だけ「いじっても影響が無い」と判断した根拠・資格情報の受け渡し方法・テストデータの後始末をユーザーから聞いて記入する（本番は許可しない）
3. 検証結果の出力先を `.gitignore` に追記する
4. ランナーは雛形の「実行基盤の要件」を満たすようプロジェクト側で実装する必要がある旨を伝える（この場では実装しない．必要なら立ち上げ後に `/implement` で作る）

「今は作らない」を選んだ場合は何も作らず，後から用意できることだけ伝えて次に進む．

## フェーズ 7: 実装開始

1. GUIDE_01 の「CLAUDE.md の管理」セクションに従い，CLAUDE.md を最終更新する
   - **team モードの場合**（`.claude/project-mode` が `team`）は，ここで CLAUDE.md をチーム開発向けに変換する:
     - 「開発進捗」節を，進捗欄（最新 1 行）ではなく **Issues ポインタ**に置き換える（例: 「進捗・タスクは GitHub Issues と git 履歴で追う（GUIDE_03）．現在のタスクは `gh issue list` で確認する．`CLAUDE.md` には進捗を書かない．」）．
     - 「必須ルール（コード実装時）」に **「チーム開発（GUIDE_03 準拠）」小節**を追加する（直列運用・Issue ベースのタスク管理・`/task-create`／`/task-start`／`/task-handoff` の案内・条件付きセルフマージ・共有設定変更は専用 PR＋他メンバー 1 名 Approve 必須）．
     - 「Git 運用」小節に，セッション開始時の `[sync-check]` 警告を必ず認識する旨の 1 行を追加する．
     - 「ドキュメント」→「01_GUIDE」一覧に `GUIDE_03` の行を追加する．
   - **solo モードの場合**は従来どおり（進捗欄＋ PROGRESS.md 運用）．
2. 作成した全ドキュメントの一覧を表示する
3. 最初の実装ステップを確認する
4. **モードに関わらず**，「GitHub リポジトリのセキュリティ設定」（前述）を実行する（Phase 3 で有効化済みなら検証コマンドだけで確認する．リモートがまだ無ければ，リポジトリ作成後に ENV_03 のコマンドを実行するようユーザーに案内する）
5. CLAUDE.md の最終更新・進捗の更新を `chore/project-setup` にコミットする（前述「立ち上げ中の Git 運用」）．`main` への取り込みは行わず，ユーザーに `/commit push`（または `/commit merge`）を案内する
6. **team モードの場合**は，AI に実施できない「管理者の初期設定」（GUIDE_03「管理者の初期設定」）をユーザーに案内する:
   - GitHub リポジトリ作成・メンバー招待
   - Issue テンプレートの用意
   - CI 構築（未構築の間は GUIDE_03「CI 構築までの暫定ゲート」を適用）
   - ※ 脆弱性検出（Dependabot alerts / security updates）は上記 4 で AI が有効化済み，依存バージョン更新（`.github/dependabot.yml`）はフェーズ 3 で生成済みのため，ここでは案内しない．CI を `github-actions` で組んだら `dependabot.yml` に `github-actions` エコシステムが含まれていることを確認する（`reference.md`「依存バージョン更新の設定」）

「**全フェーズが完了しました．**

作成したドキュメント:
{ドキュメント一覧}

開発モード: {solo / team}
CLAUDE.md を更新しました．
GitHub リポジトリのセキュリティ設定（Dependabot alerts / security updates）: {有効化済み / リポジトリ未作成のため未実施（ENV_03 のコマンドで有効化してください）}
依存バージョン更新（`.github/dependabot.yml`）: {対象エコシステム一覧} を {更新頻度} で監視
Dependabot が作る PR・alert は `/deps-update` で処理できます（安全な更新は自動マージ，メジャー更新等は分析付きで報告）．
立ち上げの成果物は `chore/project-setup` に {N} コミットで積んであります．`main` への取り込みは `/commit push`（PR 作成まで）または `/commit merge`（マージまで）で行ってください．
環境構築: {実行した手順の要点 / ユーザーに依頼した手順 / 未検証のまま残した手順}
最初の実装ステップは `{ステップ名}` です．`/implement {タスク}` で開始できます．
{team の場合: 「チーム運用の管理者初期設定（GitHub repo・CI 等）は GUIDE_03 を参照してユーザー側で実施してください．」}」

## 中断時の処理

ユーザーが中断を希望した場合:

1. 現在のフェーズと状態を CLAUDE.md の「開発進捗」（最新 1 行に上書き）と `docs/PROGRESS.md`（末尾に追記）に記録する
2. ここまでの成果物と進捗の更新を `chore/project-setup` にコミットする（未コミットの差分を残さない．push・PR は行わない）
3. 次回 `/setup` 実行時に続きから再開できるようにする

「**進捗を保存しました．**

現在の状態: フェーズ {N}（{フェーズ名}）まで完了
`chore/project-setup` にコミット済みです（未コミットの変更はありません）．
次回 `/setup` を実行すると，同じブランチでフェーズ {N+1} から再開します．」