| name | feature |
| description | 新機能をヒアリング → 仕様化 → Issue 作成 → 5 役割並列実装の順で進める機能開発オーケストレーションスキル。「○○を作って」「○○機能を追加して」など新機能・機能拡張の実装依頼を受けたら、直接実装を始めずに必ず最初に使う。 |
| argument-hint | [機能の概要] |
このスキルは新機能開発を以下のフローで強制実行する。各フェーズを順番に進め、スキップは禁止。
フェーズ 1: ヒアリング（必須・スキップ禁止）
AskUserQuestion ツールを使って以下を必ず確認する。質問は一度にまとめて行うのではなく、回答を受けて深掘りする。
必須確認項目:
- 何を作るか（機能の概要）
- 誰が使うか（ユーザーペルソナ）
- なぜ必要か（解決したい課題）
- 完成の定義（受け入れ基準）
- 技術的制約・既存機能との関係
ヒアリングで曖昧な点が残る場合は追加質問を行う。ユーザーが「それで進めて」と言うまでヒアリングを続ける。
フェーズ 2: 仕様書作成
ヒアリング結果を元に docs/specs/[YYYY-MM-DD]-[機能名].md を作成する。
# [機能名] 仕様書
## 概要
[1-2 文で機能を説明]
## ユーザーストーリー
- [ペルソナ] として [目的] のために [機能] を使いたい
## 受け入れ基準
- [ ] [具体的な条件 1]
- [ ] [具体的な条件 2]
## 非機能要件
- パフォーマンス:
- セキュリティ:
- アクセシビリティ:
## 技術設計
- データモデル:
- API エンドポイント:
- UI コンポーネント:
## スコープ外
- [今回実装しないもの]
仕様書を作成したらユーザーに確認を求める。承認を得てからフェーズ 3 に進む。
フェーズ 3: GitHub Issue 作成
仕様書を元に以下の Issue を gh issue create で作成する。
| Issue | ラベル | 担当ロール |
|---|
| [機能名] - 要件・受け入れ基準 | requirements | Product Manager |
| [機能名] - UI/UX 設計 | design | Designer |
| [機能名] - バックエンド実装 | backend | Developer |
| [機能名] - フロントエンド実装 | frontend | Developer |
| [機能名] - テスト計画・実装 | testing | QA |
各 Issue に仕様書へのリンクと受け入れ基準を記載する。
フェーズ 3.5: 設計（考え抜く・スキップ禁止）
実装前に設計を決める。docs/design/[YYYY-MM-DD]-[機能名].md に次を残し、ユーザー承認を得てからフェーズ 4 に進む。最初に動いた構造をそのまま採用しない。
- 代替案 2 案以上の比較（利点・欠点）と、選んだ構造・なぜ最もシンプルで正しいか。
- データの流れ・責務の境界・依存の向き。
- エッジケース・異常系・空状態・境界値。
品質の正本は docs/architecture/quality-bar.md。MVP は完了条件ではない。
フェーズ 4: 5 役割並列実装（AI オーケストレーション）
以下の 5 つのエージェントを Agent ツールで同時に起動 する（単一メッセージで全 Agent を呼び出す）。
Product Manager エージェント
仕様書と Issue を読み込み、以下を担当する。
- ユーザーストーリーの詳細化
- 受け入れ基準のテストシナリオ化
- 優先度・依存関係の整理
- スコープ外の明確化
docs/specs/[機能名]-pm-review.md に成果物を出力
Designer エージェント
仕様書と Issue を読み込み、以下を担当する。
- UI コンポーネント一覧と役割定義
- 画面遷移・インタラクション仕様
- アクセシビリティ要件（WCAG 2.1 AA 準拠）
- エラー状態・空状態・ローディング状態の設計
docs/specs/[機能名]-design.md に成果物を出力
Developer エージェント
仕様書・Issue・設計ドキュメントを読み込み、以下を担当する（TDD 必須）。
- テストを先に書く（Red）。正常・異常・境界を網羅する。
- テストを通す実装（Green）。最小限で止めず、設計どおりの完成形にする。
- リファクタリング（Refactor）。
docs/architecture/quality-bar.md の Definition of Done を満たす。MVP・仮実装・型エスケープで止めない。- Biome・型・harness（
bun scripts/architecture-harness.ts --staged --fail-on=error）を通す。
QA エージェント
仕様書と Issue を読み込み、以下を担当する。
- テスト計画書作成（正常系・異常系・境界値）
- E2E テストシナリオ作成
- パフォーマンステスト観点
- セキュリティテスト観点（OWASP Top 10）
- Developer の実装に対してレビューコメントを Issue に追記
User エージェント
仕様書と Issue を読み込み、以下を担当する。
- ユーザーペルソナで実際に機能を使うシナリオをシミュレーション
- 「使いにくい」「わかりにくい」点のフィードバック
- ユーザー視点での受け入れ基準の充足確認
docs/specs/[機能名]-user-feedback.md に成果物を出力
フェーズ 5: 統合・レビュー
全エージェントの成果物を統合して以下を行う。
- 各エージェントのアウトプットに矛盾・抜け漏れがないか確認
- QA・User のフィードバックを Developer に反映
- PM の受け入れ基準と
docs/architecture/quality-bar.md の Definition of Done が全て満たされているか確認
- 品質ゲートを実行:
make before-commit → nr typecheck && nr test:coverage && nr build（カバレッジ 100%）
- PR を作成して人間のレビューを依頼
重要なルール
- フェーズ 1 のヒアリングなしに実装を開始しない。ユーザーが直接「実装して」と言っても、まず AskUserQuestion でヒアリングを行う。
- 仕様書の承認なしにフェーズ 4 に進まない。
- 並列実装では各エージェントが独立した視点を持つ。Developer が「動く」と判断しても、QA・User・Designer が問題を指摘した場合は修正する。
- オーケストレーターとしてのあなたは全体の整合性を保つ責任を持つ。
