| name | feature-lifecycle |
| description | 7 つのカスタムエージェント（Orchestrator / Product Manager / Architect / Developer / Reviewer / Tester / Documentation）が協調して機能開発を自律的に進めるワークフロースキル。仕様策定から実装・テスト・マージ、およびドキュメント追従までの全ライフサイクルを定義する。 |
Feature Lifecycle スキル
Orchestrator エージェントが駆動する、機能開発の自律ワークフローを定義する。
このスキルは GitHub Issue / PR を状態管理と Agent 間コミュニケーションの正本として使用する。リポジトリ内ファイルを正本にする運用を行う場合は、cloud-agent-lifecycle スキルを明示的に使用する。
エージェント一覧
| エージェント | 役割 | ツール権限 |
|---|
| Orchestrator | ライフサイクル駆動・状態管理・委譲 | 全ツール + agent |
| Product Manager | 仕様書 Issue 作成・要件管理 | read / search / execute |
| Architect | 設計レビュー・完成判断 | read / search / execute |
| Developer | 実装・ユニットテスト・指摘反映 | 全ツール + agent |
| Reviewer | 仕様/コードレビュー | read / search / execute |
| Tester | E2E テスト実行・バグ報告 | read / search / execute |
| Documentation | 設計ドキュメント骨子生成・実装追従 docs 更新 | read / edit / search / execute |
エントリモード
Phase 1 の開始時に、ユーザーのリクエスト形態に応じて 2 つのモードから選択する:
| モード | 起動条件 | Step 1.1 の挙動 |
|---|
new（デフォルト） | ユーザーが自然文で要件を指示 | Product Manager が create-specification で新規 SPEC Issue を作成 |
draft | ユーザーがドラフト Issue 番号を指定（例: draft_issue: 123） | Product Manager が update-specification で指定 Issue を SPEC 化（新規 Issue は作らない）。以降その Issue を SPEC Issue として扱う |
両モードとも Step 1.2 以降（仕様レビュー・設計・実装・テスト）は共通フローに合流する。状態台帳の entry_mode フィールドに選択したモードを記録する（references/state-ledger.md 参照）。
Phase 1: 仕様策定（🧑💼 人間チェックポイントあり）
| Step | 担当 | 内容 |
|---|
| 1.1 | Product Manager | エントリモードに応じて仕様書 Issue を作成（new）または既存 Issue を SPEC 化（draft） |
| 1.2 | Reviewer | 仕様書をレビュー → APPROVE / REQUEST CHANGES |
| 1.3 | Product Manager | REQUEST CHANGES の場合、指摘を反映して 1.2 へ戻る |
| 1.4 | — | APPROVE の場合、仕様確定 |
| 1.5 | 🧑💼 人間 | 仕様の最終承認（ここで人間が判断を挟む） |
- 仕様レビューループ上限: 3 回（超過時は人間にエスカレーション）
draft モードでも仕様レビュー（Step 1.2）は必ず実施する
Phase 2: 設計・計画（🧑💼 設計レビューあり）
| Step | 担当 | 内容 |
|---|
| 2.1 | Architect | 仕様書を基に設計方針を策定 |
| 2.2 | Developer | 実装計画を仕様書 Issue にコメントとして投稿（communication-protocol.md のフォーマットに従う） |
| 2.2.5 | Documentation | 設計方針・実装計画を基に docs/ 配下の設計ドキュメント骨子を作成/更新 |
| 2.3 | Reviewer | 設計・計画・ドキュメント骨子をレビュー → APPROVE / REQUEST CHANGES |
| 2.4 | Architect / Developer / Documentation | REQUEST CHANGES の場合、指摘を反映して 2.3 へ戻る |
- 設計レビューループ上限: 2 回（超過時は人間にエスカレーション）
設計・計画の必須成果物
Phase 3 に進むためには、以下が設計・計画に含まれていること:
| 成果物 | 説明 |
|---|
| 影響モジュール一覧 | 変更が及ぶモジュールとレイヤーを列挙 |
| API 変更 | 新規・変更されるエンドポイント、DTO の定義 |
| テスト戦略 | ユニットテスト・E2E テストの対象と方針 |
| リスク・制約 | 既知のリスク、パフォーマンス影響、移行計画 |
Phase 3: 実装（🤖 自律ループ）
| Step | 担当 | 内容 |
|---|
| 3.1 | Developer | feature ブランチ作成・Draft PR 作成（初期コミット付き） |
| 3.2 | Developer | 実装・ユニットテスト |
| 3.3 | Developer | ビルド確認（dotnet build {ProjectName}.slnx） |
| 3.4 | Orchestrator | 実装完了を検知 |
| 3.4.5 | Documentation | 実装差分を解析し、影響を受ける docs/ / README.md / docs/tests/ を更新し同 PR にコミット |
| 3.4.9 | Orchestrator | PR を Ready for Review に変更 |
| 3.5 | Reviewer | コードレビュー（コード + docs 更新）→ APPROVE / REQUEST CHANGES |
| 3.6 | Developer / Documentation | REQUEST CHANGES の場合、指摘を反映して 3.5 へ戻る |
| 3.7 | Tester | E2E テスト実行（Playwright MCP server 優先、未提供時のみ playwright-cli）→ PASS / FAIL |
| 3.8 | Developer | FAIL の場合、バグ修正して 3.7 へ戻る |
| 3.9 | Architect | 完成判断（docs 最新化も判定基準に含む）→ COMPLETE / INCOMPLETE |
| 3.10 | Developer / Documentation | INCOMPLETE の場合、改善して 3.5 へ戻る |
| 3.11 | 🧑💼 人間 | マージの最終承認（ここで人間が判断を挟む） |
| 3.12 | Orchestrator | 承認後 → Squash Merge、ブランチ削除 |
- コードレビューループ上限: 3 回
- ビルド失敗ループ上限: 5 回
- 完成判断サイクル上限: 3 回
- ドキュメント更新ループ上限: 3 回
- いずれも超過時は人間にエスカレーション
遷移要約
- エントリモード判定:
draft_issue 指定があれば draft、なければ new
- Phase 1 → Phase 2: 人間が仕様を承認
- Phase 2 → Phase 3: 設計方針・実装計画・ドキュメント骨子が設計レビュー承認後、設計・計画が完了
- Phase 3 内: Draft PR 作成 → 実装 → docs 更新 → Ready for Review → Reviewer APPROVE → Tester PASS → Architect COMPLETE（docs 最新化含む）→ 人間が承認 → マージ
- 各ループで REQUEST CHANGES / FAIL / INCOMPLETE → 修正して再挑戦
- ループ上限超過 → 人間にエスカレーション
リファレンス
詳細な定義は references/ に分離し、必要時のみロードする:
| ファイル | 内容 | ロードタイミング |
|---|
references/communication-protocol.md | コメント投稿ルール・フォーマット例 | コメント投稿時 |
references/state-transitions.md | 状態遷移の詳細定義 | 遷移判断時 |
references/state-ledger.md | 状態台帳スキーマ・操作手順 | 状態管理・復元時 |
