Newer
Older
programming-template / .claude / skills / setup / SKILL.md

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

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

基本ルール

  • 各フェーズの成果物をユーザーが承認し,コミット済みであること(未コミットの場合は,そのまま進んでよいかのユーザーの了承)を確認してから次のフェーズに進むこと(後述「立ち上げ中の Git 運用」)
  • ユーザーが「今日はここまで」と言った場合,CLAUDE.md の進捗(最新 1 行)と docs/PROGRESS.md(追記)を更新して中断する
  • ドキュメントの書式・命名は .claude/rules/markdown-style.md・.claude/rules/docs-naming.md に従って作成する(該当ファイル編集時に自動ロードされる)
  • 成果物は最初から保存先にファイルとして書き出してからレビューを受ける.チャットには成果物の全文を出さず,「書き出したファイルの一覧」と「判断してほしい点・Claude が決めた点」だけを短く示す(ユーザーはエディタでファイルを読む)
  • ユーザーの修正指示はファイルに直接反映する(差分はユーザーが git diff で追える).修正内容はチャットに要点だけ報告し,全文を再掲しない
  • フォルダは成果物を実際に書き出すときにのみ作成する.空のカテゴリフォルダを先回りで作らない

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

立ち上げ作業は専用ブランチ chore/project-setup の上で行う.コミットは本スキルでは行わず,各フェーズの成果物をユーザーが確認したうえでユーザー自身が /commit で行う(CLAUDE.md「Git 運用」の「/commit 自発実行禁止」どおり).フェーズごとのコミットメッセージ例は本スキルの reference.md(.claude/skills/setup/reference.md)「フェーズごとのコミット」にあり,ユーザーに案内してよい.

  • ブランチ chore/project-setup の作成は本スキルが行ってよい.最初にファイルを書き換える前(前提確認での CLAUDE.md 書き換えを含む)に main から作成する.既に chore/project-setup にいる場合(再開時)はそのまま使い続ける(手順は reference.md「フェーズごとのコミット」)
  • git commit・git push・PR 作成・マージは行わない.main への取り込みは全フェーズ完了後にユーザーが /commit push(または /commit merge)で行う
  • 次のフェーズに進む前に git status --porcelain で作業ツリーがクリーン(そのフェーズの成果物がコミット済み)であることを確認する.未コミットの変更が残っている場合は,コミットしてから進むか,未コミットのまま次へ進むかをユーザーに確認する(勝手に進まない)
  • フェーズごとにコミットしてもらうことで,中断・再開しても「どこまで終わったか」が 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 を確認し,どのフェーズから再開するか判断する(再開時は git status --porcelain で前回の未コミットの変更が残っていないかも確認し,残っていればユーザーに /commit するか確認する)
  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 ブロックは保持する):
      "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. 成果物を GUIDE_01 に記載された保存先に直接書き出し,書き出したファイルの一覧と要確認点をユーザーに示す(全文はチャットに出さない)
  4. ユーザーの修正指示をファイルに反映し,承認を得る
  5. ユーザーに /commit でのコミットを案内する(前述「立ち上げ中の Git 運用」・reference.md「フェーズごとのコミット」のメッセージ例を添える)
  6. 作業ツリーがクリーンになったことを確認してから次のフェーズに進む(未コミットのまま進むかはユーザーに確認する)

台詞テンプレート

「フェーズ {N}({フェーズ名})の成果物を書き出しました. エディタで確認してください.

書き出したファイル:

  • {ファイルパス}({新規作成 / 更新}: {1 行の説明})

判断してほしい点:

  • {ユーザーの判断が必要な点.無ければ「なし」}

Claude が決めた点:

  • {ユーザーに確認せず Claude が仮に決めた点と理由}

修正点があれば指示してください(ファイルを直接修正します.差分は git diff で確認できます). OK であれば /commit でコミットしてください(メッセージ例: {reference.md の対応表のメッセージ例}).コミットを確認してから次のフェーズに進みます.」

修正を反映したときは,直したファイルと変更点の要点だけを示し,同様に /commit を案内する.

フォルダ作成の注意

成果物を書き出すフォルダのみ作成する..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 の最終更新・進捗の更新をユーザーに確認してもらい,/commit でのコミットを案内する(前述「立ち上げ中の Git 運用」).その後の main への取り込みも本スキルでは行わず,ユーザーに /commit push(または /commit merge)を案内する(最終更新のコミットと取り込みを 1 回の /commit push 等でまとめて行ってよい)
  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 ブランチにあります(CLAUDE.md の最終更新は未コミットです.内容を確認してください).コミットと main への取り込みは /commit push(PR 作成まで)または /commit merge(マージまで)で行ってください. 環境構築: {実行した手順の要点 / ユーザーに依頼した手順 / 未検証のまま残した手順} 最初の実装ステップは {ステップ名} です./implement {タスク} で開始できます. {team の場合: 「チーム運用の管理者初期設定(GitHub repo・CI 等)は GUIDE_03 を参照してユーザー側で実施してください.」}」

中断時の処理

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

  1. 現在のフェーズと状態を CLAUDE.md の「開発進捗」(最新 1 行に上書き)と docs/PROGRESS.md(末尾に追記)に記録する
  2. 本スキルではコミットしない.未コミットの成果物と進捗の更新があれば,書き出したファイルの一覧を示し,ユーザーに /commit でのコミットを案内する(コミットせずに中断してもよいが,その場合は未コミットの変更が残っていることを伝える)
  3. 次回 /setup 実行時に続きから再開できるようにする

「進捗を記録しました.

現在の状態: フェーズ {N}({フェーズ名})まで完了 未コミットのファイル:

  • {ファイルパス}(無ければ「なし」)

未コミットのファイルがある場合は,chore/project-setup で /commit を実行してコミットしておくことを推奨します(メッセージ例: {メッセージ例}). 次回 /setup を実行すると,同じブランチでフェーズ {N+1} から再開します.」