概要

Step 2: コードベース調査（Explore エージェント）

以下を調査させ、調査サマリーをメインに返させる:

• docs/specs/ 配下の現状（存在する場合 — 画面一覧・ER図等の既存内容を把握）
• docs/architecture/ のアーキテクチャ定義（ディレクトリ構造・命名規則・使用技術）
• issueに関連する既存コードのパターン・ディレクトリ構造
• 使用しているバックエンドフレームワーク（FastAPI/Laravelなど — Step3でのOpenAPI生成方針の判断に使う）

Exploreエージェントへの指示例:

以下を調査してサマリーを返してください:
1. docs/specs/ の現状（存在すれば各ファイルの内容）
2. docs/architecture/ のアーキテクチャ定義
3. issue内容「<issueタイトルと概要>」に関連する既存コード
4. バックエンドフレームワーク（package.json, requirements.txt, composer.json等から判断）

Step 3: アウトプット生成（general-purpose エージェント）

Step2の調査サマリーをコンテキストとして渡し、以下を即時ファイル保存させる。 処理ロジックは一切書かない。型・構造・インターフェースの定義のみ。

API定義（APIエンドポイントの追加・変更がある場合のみ）:

画面仕様（画面の追加・変更がある場合のみ）:

コンポーネントのProps定義・表示要件を実際のコードベース（既存ディレクトリ構造に合わせた場所）に保存する。

general-purposeエージェントへの指示例:

以下の調査サマリーとissue内容をもとに、アウトプットを生成してください。
[調査サマリー]
[issue内容]

- 処理ロジックは書かない（型・構造定義のみ）
- 既存のディレクトリ構造・命名規則に従う
- 生成したファイルの一覧を返してください

Step 4: ドキュメント更新（メイン）

以下を即時ファイル保存する。変更がない項目はスキップ。 docs/specs/ のファイルが存在しない場合は docs/template/ からコピーして新規作成する。

api-list.md は人間が読む概要一覧、openapi.yaml は機械可読の完全仕様。役割が異なるため両方を維持する。

Step 5: 人間への確認・フィードバック反映（メイン）

1. 生成・更新したファイルの一覧と変更概要をユーザーに提示する
2. フィードバックを受けて修正する（複数回対応）
3. ユーザーが確定したら、以下を gh issue comment でissueに記録する:
   • フィードバック内容（何をどう変えたか）
   • 確定した仕様のサマリー（どのファイルが確定したか）
4. 「要件定義フェーズが完了しました」と伝えてフェーズ終了

注意事項

• gh コマンドが使えない場合はエラーをそのままユーザーに伝える
• アーキテクチャ定義（docs/architecture/）を必ず参照し、既存コードの命名規則・ディレクトリ構造に従う
• 変更が不要なドキュメントは更新しない（空振りの更新をしない）
• issueに記録するコメントは日本語で書く