feature-lifecycle

# Feature Lifecycle スキル Orchestrator エージェントが駆動する、機能開発の自律ワークフローを定義する。 --- ## エージェント一覧 | エージェント | 役割 | ツール権限 | |---|---|---| | **Orchestrator** | ライフサイクル駆動・状態管理・委譲 | 全ツール + agent | | **Product Manager** | 仕様書 Issue 作成・要件管理 | read / search / execute | | **Architect** | 設計レビュー・完成判断 | read / search / execute | | **Developer** | 実装・ユニットテスト・指摘反映 | 全ツール + agent | | **Reviewer** | 仕様/コードレビュー | read / search / execute | | **Tester** | E2E テスト実行・バグ報告 | read / search / execute | --- ## Phase 1: 仕様策定（人間チェックポイントあり） | Step | 担当 | 内容 | |------|------|------| | 1.1 | Product Manager | ユーザー要件を分析し、仕様書 Issue を作成（`github-flow`: `gh issue create` / `local-flow`: `issues/` に Markdown 作成） | | 1.2 | Reviewer | 仕様書をレビュー → APPROVE / REQUEST CHANGES | | 1.3 | Product Manager | REQUEST CHANGES の場合、指摘を反映して 1.2 へ戻る | | 1.4 | — | APPROVE の場合、仕様確定 | | 1.5 | **人間** | **仕様の最終承認**（ここで人間が判断を挟む） | - 仕様レビューループ上限: **3 回**（超過時は人間にエスカレーション） --- ## Phase 2: 設計・計画 | Step | 担当 | 内容 | |------|------|------| | 2.1 | Architect | 仕様書を基に設計方針を策定 | | 2.2 | Developer | 実装計画を作成（`update-implementation-plan` スキル使用） | --- ## Phase 3: 実装（自律ループ） | Step | 担当 | 内容 | |------|------|------| | 3.1 | Developer | feature ブランチ作成・実装・ユニットテスト | | 3.2 | Developer | ビルド確認（`cd src && dotnet build <YourSolution>.slnx`） | | 3.3 | Developer | Draft PR 作成（`github-flow`: `gh pr create --draft` / `local-flow`: `pull-requests/` に Markdown 作成） | | 3.4 | Reviewer | コードレビュー → APPROVE / REQUEST CHANGES | | 3.5 | Developer | REQUEST CHANGES の場合、指摘を反映して 3.4 へ戻る | | 3.6 | Tester | E2E テスト実行 → PASS / FAIL | | 3.7 | Developer | FAIL の場合、バグ修正して 3.6 へ戻る | | 3.8 | Architect | 完成判断 → COMPLETE / INCOMPLETE | | 3.9 | Developer | INCOMPLETE の場合、改善して 3.4 へ戻る | | 3.10 | Orchestrator | COMPLETE → PR を Ready for Review に変更（`local-flow`: ステータスを `review` に更新） | | 3.11 | **人間** | **マージの最終承認**（ここで人間が判断を挟む） | | 3.12 | Orchestrator | 承認後 → Squash Merge、ブランチ削除（`local-flow`: `git merge --squash`、ステータス更新） | - コードレビューループ上限: **3 回** - ビルド失敗ループ上限: **5 回** - 完成判断サイクル上限: **3 回** - いずれも超過時は人間にエスカレーション --- ## 遷移要約 1. Phase 1 → Phase 2: 人間が仕様を承認 2. Phase 2 → Phase 3: 設計・計画が完了 3. Phase 3 内: Reviewer APPROVE → Tester PASS → Architect COMPLETE → 人間が承認 → マージ 4. 各ループで REQUEST CHANGES / FAIL / INCOMPLETE → 修正して再挑戦 5. ループ上限超過 → 人間にエスカレーション --- ## リファレンス 詳細な定義は `references/` に分離し、必要時のみロードする: | ファイル | 内容 | ロードタイミング | |---------|------|-----------------| | `references/communication-protocol.md` | コメント投稿ルール・フォーマット例 | コメント投稿時 | | `references/state-transitions.md` | 状態遷移の詳細定義 | 遷移判断時 |