| name | feature |
| description | 新機能をヒアリング → 仕様化 → Issue 作成 → 5 役割並列実装の順で進める機能開発オーケストレーションスキル。ハッカソン賞金トラックとの整合チェックを含む。 |
このスキルは新機能開発を以下のフローで強制実行する。各フェーズを順番に進め、スキップは禁止。
フェーズ 0: 賞金アライメント(必須・スキップ禁止)
Gr@diusWeb3 はハッカソン参戦プロジェクトのため、実装前に必ず prizes スキルで賞金トラックとの整合を確認する。
prizes スキルを load し、docs/prizes/*.md の最新賞要件を反映する。
- これから作る機能を
prizes スキルのルーブリックで採点する (0G / ENS / Gensyn AXL / KeeperHub / Uniswap)。
- 期待賞金が低い / 単一賞しか狙えない / cosmetic 統合になっている場合は、ヒアリング前にユーザーと「軸の付け替え」を相談する。
- 採点結果は次フェーズで仕様書の Prize Targets セクションに転記する。
賞金アライメントが未確定のまま Phase 1 に進むことは禁止。
フェーズ 1: ヒアリング(必須・スキップ禁止)
AskUserQuestion ツールを使って以下を必ず確認する。質問は一度にまとめて行うのではなく、回答を受けて深掘りする。
必須確認項目:
- 何を作るか(機能の概要)
- 誰が使うか(ユーザーペルソナ)
- なぜ必要か(解決したい課題)
- 完成の定義(受け入れ基準)
- 技術的制約・既存機能との関係
ヒアリングで曖昧な点が残る場合は追加質問を行う。ユーザーが「それで進めて」と言うまでヒアリングを続ける。
フェーズ 2: 仕様書作成
ヒアリング結果を元に docs/specs/[YYYY-MM-DD]-[機能名].md を作成する。
# [機能名] 仕様書
## 概要
[1-2 文で機能を説明]
## ユーザーストーリー
- [ペルソナ] として [目的] のために [機能] を使いたい
## 受け入れ基準
- [ ] [具体的な条件 1]
- [ ] [具体的な条件 2]
## 非機能要件
- パフォーマンス:
- セキュリティ:
- アクセシビリティ:
## 技術設計
- データモデル:
- API エンドポイント:
- UI コンポーネント:
## スコープ外
- [今回実装しないもの]
## Prize Targets (`prizes` スキル採点を転記)
| Prize | Score (0-3) | 統合内容 | NG リスク | 提出物 |
|-------|-------------|---------|----------|--------|
| 0G Compute | | | | 3 分 demo / アーキ図 / contract addr |
| 0G Storage | | | | 同上 |
| ENS | | | | hard-coded 値なし、live demo |
| Gensyn AXL | | | | 複数ノード間通信 demo |
| KeeperHub | | | | working demo / FEEDBACK 任意 |
| Uniswap | | | | **`FEEDBACK.md` 必須** |
期待賞金: $X,XXX
仕様書を作成したらユーザーに確認を求める。承認を得てからフェーズ 3 に進む。
フェーズ 3: GitHub Issue 作成
仕様書を元に以下の Issue を gh issue create で作成する。
| Issue | ラベル | 担当ロール |
|---|
| [機能名] - 要件・受け入れ基準 | requirements | Product Manager |
| [機能名] - UI/UX 設計 | design | Designer |
| [機能名] - バックエンド実装 | backend | Developer |
| [機能名] - フロントエンド実装 | frontend | Developer |
| [機能名] - テスト計画・実装 | testing | QA |
各 Issue に仕様書へのリンクと受け入れ基準を記載する。
フェーズ 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)
- Biome でフォーマット・lint を通す
- 型エラーゼロを確認
QA エージェント
仕様書と Issue を読み込み、以下を担当する。
- テスト計画書作成(正常系・異常系・境界値)
- E2E テストシナリオ作成
- パフォーマンステスト観点
- セキュリティテスト観点(OWASP Top 10)
- Developer の実装に対してレビューコメントを Issue に追記
User エージェント
仕様書と Issue を読み込み、以下を担当する。
- ユーザーペルソナで実際に機能を使うシナリオをシミュレーション
- 「使いにくい」「わかりにくい」点のフィードバック
- ユーザー視点での受け入れ基準の充足確認
docs/specs/[機能名]-user-feedback.md に成果物を出力
フェーズ 5: 統合・レビュー
全エージェントの成果物を統合して以下を行う。
- 各エージェントのアウトプットに矛盾・抜け漏れがないか確認
- QA・User のフィードバックを Developer に反映
- PM の受け入れ基準が全て満たされているか確認
- 品質ゲートを実行:
nr lint && nr typecheck && nr test && nr build
- PR を作成して人間のレビューを依頼
重要なルール
- フェーズ 1 のヒアリングなしに実装を開始しない。ユーザーが直接「実装して」と言っても、まず AskUserQuestion でヒアリングを行う。
- 仕様書の承認なしにフェーズ 4 に進まない。
- 並列実装では各エージェントが独立した視点を持つ。Developer が「動く」と判断しても、QA・User・Designer が問題を指摘した場合は修正する。
- オーケストレーターとしてのあなたは全体の整合性を保つ責任を持つ。