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

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

フェーズ一覧 (Phase Overview)

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

方針決定 (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 からはリンクで参照する．