# プロジェクト立ち上げフロー (Project Setup Flow)

新規プロジェクトを AI と協働で立ち上げる際の手順を定義する．
各フェーズを順番に進め，成果物を確定させてから次のフェーズに移ること．

## フェーズ一覧 (Phase Overview)

| フェーズ | やること                                       | 成果物                                                     |
| -------- | ---------------------------------------------- | ---------------------------------------------------------- |
| 方針決定 | プロジェクトの目的・スコープを決める           | `PLAN_01_要件定義書.md`                                    |
| 技術選定 | 言語・フレームワーク・インフラを決める         | `ENV_01_技術スタック.md`                                   |
| 環境構築 | 開発環境のセットアップ手順を整備する           | `ENV_02_環境構築手順.md`，`ENV_03_管理者用環境構築手順.md` |
| 仕様設計 | アーキテクチャ・データモデル・画面設計を決める | `SPEC_01_*.md`                                             |
| 規約整備 | 技術スタックに応じたコーディング規約を作る     | `.claude/rules/*.md`                                       |
| 開発計画 | ステップを分割し，開発順序を決める             | `PLAN_02_開発ステップ.md`                                  |
| 実装開始 | 開発計画に沿って実装を進める                   | ソースコード                                               |

※ 立ち上げフローで作成するのは `02_ENV / 03_PLAN / 04_SPEC` カテゴリの成果物と，規約整備フェーズの `.claude/rules/*.md` のみ．`05_TECH`（技術設計）・`06_TEST`（テスト）は実装フェーズで必要になった時点で作成し，立ち上げ時に空フォルダを作らない．

## 開発モードとファイル構成 (Development Modes & File Layout)

プロジェクトは個人開発（solo）とチーム開発（team）の 2 モードで運用できる．モードは `/setup` の冒頭で選択し，`.claude/project-mode` に記録される（後からの切り替えは `/set-mode <solo|team>`）．

| レイヤ | 対象 | 存在するモード |
| --- | --- | --- |
| 共通層 | `GUIDE_01`・`GUIDE_02`，`.claude/rules/` のすべて，`.claude/agents/`，skills（`commit`・`implement`・`setup`・`sync-template`・`set-mode`・`auto-refactor`・`auto-audit`） | solo・team 両方 |
| team 層 | `GUIDE_03`，skills（`task-create`・`task-start`（+ `reference.md`）・`task-handoff`），`.claude/hooks/check_sync.sh`，`settings.json` の SessionStart 配線 | team のみ |

- `.claude/rules/` はすべて共通層だが，進捗記録ルール（`progress-log`）だけは team モードで運用上**上書き**される（進捗は `CLAUDE.md`／`docs/PROGRESS.md` ではなく GitHub Issues と git 履歴で追う．GUIDE_03）．
- team 層ファイルの配置・削除は `/set-mode` が一括で行い，`/sync-template` は `.claude/project-mode` を見て team 層の同期可否を判定する．team 層ファイルの正確なリストは `/set-mode`・`/sync-template` の定義に持たせており，増減時は両者を一致させること．

## 方針決定 (Direction)

プロジェクトの全体像を明確にする．

- **人間が決めること**: プロジェクトの目的，対象ユーザー，スコープ（やること・やらないこと）
- **AI に依頼できること**: 要件の整理・構造化，類似プロジェクトの調査，要件定義書のドラフト作成
- **成果物**: `PLAN_01_要件定義書.md`

## 技術選定 (Tech Stack)

要件に基づいて技術スタックを決定する．

- **人間が決めること**: 最終的な技術選定の判断，チームのスキルセットとの適合性
- **AI に依頼できること**: 要件に適した技術の候補提案，各候補のメリット・デメリット比較
- **成果物**: `ENV_01_技術スタック.md`

## 環境構築 (Environment Setup)

開発環境を構築し，手順をドキュメント化する．初回のみの管理者作業と，メンバーが繰り返し行う構築手順を分けて整備する．

- **前提条件**: 以下のツールは全プロジェクト共通で導入する．
  - `git` — バージョン管理（運用ルールは `.claude/rules/git-conventions.md` で定義）
  - `gh` — GitHub CLI（PR 作成・マージ等に使用）
- **基本方針**: 環境の再現性を重視し，手順書だけに頼らず構築を自動化・コード化できる方法を優先する（例: Docker，Dev Containers，Windows Sandbox，IaC ツール等）．
- **人間が決めること**: 開発マシンの選定，クラウドサービスのアカウント作成，環境構築方法の選択
- **AI に依頼できること**: 環境構築手順書の作成，設定ファイルの生成，`.gitignore` の作成，Dockerfile や devcontainer.json 等の構築用ファイルの作成
- **成果物**:
  - `ENV_02_環境構築手順.md` — メンバーの参加時や環境の再構築時に使う手順
  - `ENV_03_管理者用環境構築手順.md` — プロジェクト作成時に一度だけ行う初期設定（リポジトリ作成，外部サービスの設定等）

## 仕様設計 (Specification)

アプリケーションの設計を行う．

- **人間が決めること**: ユーザー体験の方針，ビジネスロジックの最終判断
- **AI に依頼できること**: アーキテクチャ設計のドラフト，データモデル定義，画面遷移図の整理
- **成果物**: `SPEC_01_*.md`（プロジェクトの規模に応じて複数ファイルに分割）

## 規約整備 (Coding Standards)

技術スタックに応じたプロジェクト固有の規約を作成する．
汎用の規約（Git 運用・ドキュメント書式・ファイル命名・進捗記録）はテンプレートの `.claude/rules/` に含まれているため，ここでは技術スタック固有の規約を追加する．

- **基本方針**: 言語・フレームワークの公式ガイドラインや広く採用されている標準規約に則る（例: Effective Dart，PEP 8，Google Style Guide 等）．プロジェクト固有のルールは標準と異なる部分のみ定義する．
- **置き場所**: 「コードを書くときは常に X せよ」という指示型の規約は，docs ではなく **path-scoped rule**（`.claude/rules/*.md` の frontmatter に `paths:` を付けたもの）として作成する．該当ファイルの編集時に自動ロードされるため，規約の読ませ忘れが起きない．アーキテクチャの背景説明や設計判断の記録など「読み物・参照資料」は従来どおり docs（`04_SPEC`／`05_TECH`）に置く．
- **人間が決めること**: 標準規約でカバーされない判断（アーキテクチャパターンの選択等）
- **AI に依頼できること**: 標準規約を踏まえた規約のドラフト作成，参照元ガイドラインの調査
- **作成すべき rule**（`paths` はプロジェクトの実際のディレクトリ構成に合わせて設定する）:
  - `.claude/rules/coding-style.md` — 命名規則，フォーマット，import 順序，型の使い方，コメントの書き方，コード内ドキュメントの規則（例: `paths: ["src/**", "lib/**"]`）
  - `.claude/rules/project-structure.md` — プロジェクトのディレクトリ構成とファイル配置ルール（`paths` はソースディレクトリ全般）
  - `.claude/rules/testing.md` — テストの種類，粒度，実行タイミング，カバレッジ基準，モック方針，テストファイルの配置規則（例: `paths: ["test/**", "**/*.test.*"]`）
  - `.claude/rules/error-handling.md` — エラーの分類，処理方法，ログ出力の方針（`paths` はソースディレクトリ全般）
  - ※ リファクタリング方針は言語に依存しないため，`.claude/agents/refactorer.md` の判断基準を共通ルールとして使用する
  - ※ 機能実装完了フローは GUIDE_02 と `/implement` で定義済みのため，別途作成しない
  - ※ 規約以外の運用フロー文書を `docs/01_GUIDE/` に追加する場合は，team 層の `GUIDE_03` との衝突を避けるため `GUIDE_04` 以降の番号を使う

## 開発計画 (Development Plan)

実装の順序とステップを決定する．

- **人間が決めること**: 優先度，リリース計画，マイルストーン
- **AI に依頼できること**: 仕様を元にしたステップ分割の提案，依存関係の整理
- **成果物**: `PLAN_02_開発ステップ.md`

## 実装開始 (Implementation)

開発計画に沿って AI と協働で実装を進める．

- 各ステップの完了時に Git 規約（`.claude/rules/git-conventions.md`）に従ってコミット・PR を作成する（ドキュメント書式は `.claude/rules/markdown-style.md` が自動適用される）．
- 仕様変更が発生した場合は，先にドキュメントを更新してから実装に反映する．

## CLAUDE.md の管理 (CLAUDE.md Management)

`CLAUDE.md` は AI が会話開始時に最初に読むファイルであり，プロジェクトの引継ぎ情報を一元管理する．
AI は毎回新しい会話で始まるため，このファイルが唯一の継続的な文脈となる．

### 記載すべき内容

- **プロジェクト概要**: プロジェクト名，目的，技術スタックの要約
- **開発進捗**: 現在のステップ（最新 1 行のみ）．詳細な進捗履歴は `docs/PROGRESS.md` に追記する（進捗記録ルール `.claude/rules/progress-log.md` 参照）
- **必須ルール**: AI が実装時に必ず守るべきルール（コーディング規約，コミット前チェック等の要点）
- **ドキュメント一覧**: docs/ 内のファイルへの参照パス

### 更新タイミング

- ステップの完了時に開発進捗を更新する（CLAUDE.md は最新 1 行に上書き，`docs/PROGRESS.md` は末尾に追記）
- ドキュメントの追加・削除・リネーム時に参照パスを更新する
- 必須ルールに変更があった場合に反映する

### 運用上の注意

- CLAUDE.md は AI が毎回読み込むため，簡潔に保つ．詳細は docs/ のドキュメントに委ね，CLAUDE.md には要点と参照先のみ記載する．
- 進捗記録は二段構成（CLAUDE.md = 最新 1 行 / `docs/PROGRESS.md` = 追記型フルログ）で管理する．詳細は `.claude/rules/progress-log.md` を参照．
- プロジェクト固有のルールが増えたら，docs/ に独立ファイルとして切り出し，CLAUDE.md からはリンクで参照する．