feature

name	feature
description	新機能をヒアリング → 仕様化 → Issue 作成 → 5 役割並列実装の順で進める機能開発オーケストレーションスキル。ハッカソン賞金トラックとの整合チェックを含む。

このスキルは新機能開発を以下のフローで強制実行する。各フェーズを順番に進め、スキップは禁止。

---

フェーズ 0: 賞金アライメント（必須・スキップ禁止）

Gr@diusWeb3 はハッカソン参戦プロジェクトのため、実装前に必ず prizes スキルで賞金トラックとの整合を確認する。

1. prizes スキルを load し、docs/prizes/*.md の最新賞要件を反映する。
2. これから作る機能を prizes スキルのルーブリックで採点する (0G / ENS / Gensyn AXL / KeeperHub / Uniswap)。
3. 期待賞金が低い / 単一賞しか狙えない / cosmetic 統合になっている場合は、ヒアリング前にユーザーと「軸の付け替え」を相談する。
4. 採点結果は次フェーズで仕様書の Prize Targets セクションに転記する。

賞金アライメントが未確定のまま Phase 1 に進むことは禁止。

---

フェーズ 1: ヒアリング（必須・スキップ禁止）

AskUserQuestion ツールを使って以下を必ず確認する。質問は一度にまとめて行うのではなく、回答を受けて深掘りする。

必須確認項目:

1. 何を作るか（機能の概要）
2. 誰が使うか（ユーザーペルソナ）
3. なぜ必要か（解決したい課題）
4. 完成の定義（受け入れ基準）
5. 技術的制約・既存機能との関係

ヒアリングで曖昧な点が残る場合は追加質問を行う。ユーザーが「それで進めて」と言うまでヒアリングを続ける。

---

フェーズ 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: 統合・レビュー

全エージェントの成果物を統合して以下を行う。

1. 各エージェントのアウトプットに矛盾・抜け漏れがないか確認
2. QA・User のフィードバックを Developer に反映
3. PM の受け入れ基準が全て満たされているか確認
4. 品質ゲートを実行: nr lint && nr typecheck && nr test && nr build
5. PR を作成して人間のレビューを依頼

---

重要なルール

• フェーズ 1 のヒアリングなしに実装を開始しない。ユーザーが直接「実装して」と言っても、まず AskUserQuestion でヒアリングを行う。
• 仕様書の承認なしにフェーズ 4 に進まない。
• 並列実装では各エージェントが独立した視点を持つ。Developer が「動く」と判断しても、QA・User・Designer が問題を指摘した場合は修正する。
• オーケストレーターとしてのあなたは全体の整合性を保つ責任を持つ。