PRD ジェネレータ v3.0 — GitHub Issue + Shape-Spec パイプライン

包括的でコンプロマイズなしの PRD を生成し、GitHub issues として公開し、スコープ認識型のオーケストレーション プロンプトで /agent-os:shape-spec をトリガーします。これにより Opus 4.6、ワンショット配信、および最終検証としての /pr-handoff-to-codex を実行します。

ソース属性: このバンドルスキルは anombyte93/prd-taskmaster をソースとしており、下流のタスク オーケストレーション用に Task Master / task-master-ai を参照します。

このスキルを使用する場合

以下の場合にアクティベートします:

• ユーザーが PRD またはプロダクト要件ドキュメントをリクエストしている
• 「PRD が欲しい」「要件を作成して」「要件を書いて」と言っている
• 実装向けに機能を計画するよう要求している
• プロダクト/機能要件をエンジニアリング向けにドキュメント化したい

以下の場合はアクティベート しません:

• コード ドキュメンテーション(API ドキュメント、技術リファレンス)
• テスト仕様または QA ドキュメンテーション
• プロダクト コンテキストのないプロジェクト管理タイムライン
• PDF ドキュメント作成

コア原則

何も延期されない。決して。 フェーズは作業をシーケンシングするためには問題ありません。しかし「ナイストゥハブ」「今後の作業」「ストレッチ ゴール」「後で」といったものはありません。PRD 内のすべての要件は必須配信です。構築するほど重要ではないものがあれば、それはそもそも PRD に含めるべきではありません。

GitHub Issue は信実のソース 完全な PRD は GitHub issue として公開されます。これがエージェント、shape-spec、および pr-handoff-to-codex が参照するものです。

Shape-Spec が実行をオーケストレート PRD が公開された後、計画、並列化、エージェント選択、および品質管理を処理する包括的なプロンプトで /agent-os:shape-spec がトリガーされます。

すべてが Opus 4.6 すべてのエージェントは Opus 4.6 で実行されます。例外はありません。コスト削減のダウングレードはありません。

ワンショット配信 計画はできるだけワンショットで実行できるものであるべきです。説明質問と前提条件が最初に来て、その後実行は完了まで実行されます。

クリエイティブなツール使用法 エージェントは CLI ツール、MCP サーバー、/brand-guidelines、およびすべての利用可能なリソースを活用する必要があります。作業を開始する前に常に利用可能なものを確認してください。

関心の分離

フェーズ	責務	フォーカス
PRD (このスキル)	何 を構築するか	機能設計、要件、受け入れ基準、技術アーキテクチャ
Shape-Spec (その後トリガー)	どのように 構築するか	エージェント オーケストレーション、スコープ固有のエンジニアリング スタンダード、並列化、品質ゲート

PRD は理想的な機能に対する技術アーキテクトのビジョンのように読めるべきです。技術レベルで要件を定義しますが、プラットフォーム固有の実装パターンは規定しません — それは shape-spec の役割です。

ワークフロー概要 (7 ステップ)

1. 状態確認 — 既存の PRD を検出し、GH issues をチェック
2. ディスカバリー — 対話的に要件を収集
3. PRD 生成 — 包括的でコンプロマイズなしの技術要件
4. 品質検証 — 自動チェック(延期なし強制を含む)
5. GitHub Issue 公開 — gh issue create で issue の本文として完全な PRD
6. スコープ検出 — PRD + リポジトリから iOS / Backend / GCP-Infra を自動検出、ユーザーに確認
7. Shape-Spec トリガー — ベースライン実行プロンプト + スコープ固有のエンジニアリング セクション

---

詳細な実装

ステップ 1: 状態確認

スキルがアクティベートされたときの最初のアクション:

1. 既存の PRD 関連 GH issues をチェック:
   - 実行: gh issue list --label "PRD" --state open --limit 10
   - 見つかった場合: 既存の issues を表示し、ユーザーに対応を尋ねる

2. ローカル PRD ファイルをチェック:
   - Glob: .taskmaster/docs/*.md, docs/plans/*prd*, agent-os/specs/*/plan.md
   - 見つかった場合: 既存の PRD を表示し、オプションを提供

3. 既存 PRD が見つかった場合、AskUserQuestion を使用:
   オプション:
   a. 「既存 PRD を使用」 — ステップ 5 (検証) をスキップしてステップ 6 (公開) へ
   b. 「既存 PRD を更新」 — ロード、修正、再検証
   c. 「新しい PRD を作成」 — ステップ 2 からの完全なワークフロー
   d. 「既存 PRD をレビュー」 — サマリーを表示して終了

---

ステップ 2: ディスカバリー (要件収集)

AskUserQuestion を使用して対話的に質問します。一度に 1 つの質問。

必須質問 (5 個):

1. これは何の問題を解決しますか? (ユーザーの課題、ビジネスへのインパクト)
2. ターゲット ユーザー/オーディエンスは誰ですか?
3. 提案されたソリューションまたは機能は何ですか?
4. 主要な成功指標は何ですか? (成功をどのように測定するか)
5. どのような制約が存在しますか? (技術、リソース、依存関係)

技術コンテキスト (4 個): 6. これは既存コードベース向けか、それともグリーンフィールドですか? 7. テック スタックは何ですか? (既知の場合 — リポジトリから自動検出可能) 8. 統合要件はありますか? (サードパーティ サービス、内部システム) 9. パフォーマンス/スケール要件はありますか? (ユーザー、データ量、レイテンシー)

スコープと複雑性 (2 個): 10. 推定複雑性は何ですか? (シンプルな機能、一般的なプロジェクト、複雑なシステム) 11. 他に知っておくべきことはありますか? (エッジ ケース、制約、先行技術)

スマート デフォルト:

• ユーザーが最小限の回答を提供する場合、最善の推測を使用し、仮定をドキュメント化
• 包括的な詳細にデフォルト
• 特定がない限りエンジニア オーディエンスを想定
• 可能な場合リポジトリ ファイルからテック スタックを自動検出
• スコープを削減する方法としてタイムライン期待について尋ねないこと — すべてが必須配信

---

ステップ 3: PRD 生成

技術アーキテクチャ レベルでの理想的な機能に焦点を当てた包括的な PRD を生成します。PRD は 何 を定義します — 要件、受け入れ基準、および技術設計。プラットフォーム固有の実装パターンは規定しません (それは shape-spec の役割です)。

PRD 構造 (10 セクション):

# {機能名} — プロダクト要件ドキュメント

## 1. エグゼクティブ サマリー
[2-3 文: 何、なぜ、誰向け]

## 2. 問題ステートメント
[ユーザーの課題 + ビジネスへのインパクト。具体的で測定可能。]

## 3. ゴールと成功指標
[SMART メトリクス。すべてのゴールは測定可能なターゲットを持つ。]
- ゴール 1: [メトリクス] — ターゲット: [数値]
- ゴール 2: [メトリクス] — ターゲット: [数値]

## 4. ユーザー ストーリー
[各々に受け入れ基準。ストーリーあたり最小 3 個の基準。]
- [ユーザー] として、[アクション] を望む。なぜなら [ベネフィット]
  - AC1: [テスト可能な基準]
  - AC2: [テスト可能な基準]
  - AC3: [テスト可能な基準]

## 5. 機能要件
[番号付け、テスト可能、優先度付け。すべてが必須配信。]
- REQ-001: [要件] — 優先度: 必須
- REQ-002: [要件] — 優先度: 必須
[注: 「推奨」または「可」の優先度なし。ここのすべては必須。]

## 6. 非機能要件
[曖昧さのない具体的なターゲット。]
- パフォーマンス: API レスポンス < 200ms p95
- 可用性: 99.9% uptime
- セキュリティ: [具体的要件]

## 7. 技術的考慮事項
[アーキテクチャ決定、統合ポイント、制約]

## 8. 実装フェーズ
[作業をシーケンシングするためのみ — スコープ延期のため ではない。]
- フェーズ 1: [何と理由 最初]
- フェーズ 2: [何と理由 次]
[すべてのフェーズはコミット済み。オプションなフェーズなし。]

## 9. リスクと緩和策
[既知のリスクと具体的な緩和戦略]

## 10. 受け入れ基準
[機能全体が完了したことをどうやって知るか]
- [ ] すべての REQ-XXX 要件が実装およびテスト済み
- [ ] パフォーマンス ターゲット達成
- [ ] セキュリティ レビュー合格
- [ ] PR が /pr-handoff-to-codex レビューを合格

PRD 生成の重大なルール:

1. 「スコープ外」セクションなし。 PRD に含まれていなければ、存在しません。重要であれば、それは要件です。
2. 「ナイストゥハブ」または「可」の優先度なし。 すべてが必須です。
3. 「今後の作業」または「ローンチ後」の延期なし。 フェーズは作業をシーケンシングします。延期しません。
4. ごまかす言い方なし。 「高速であるべき」ではなく「< 200ms p95」。「良い UX」ではなく「[具体的なメトリクス]」。
5. すべての要件がテスト可能。 テストを書けなければ、テストを書けるまで書き直してください。

出力: PRD を .taskmaster/docs/prd-{feature-slug}.md に書き込み

---

ステップ 4: 品質検証 (14 個の自動チェック)

必須要素 (5 個のチェック):

1. エグゼクティブ サマリーが存在(2-3 文)
2. 問題ステートメントがユーザー AND ビジネス インパクトを含む
3. すべてのゴールが SMART メトリクスを持つ
4. ユーザー ストーリーが受け入れ基準を持つ(ストーリーあたり最小 3 個)
5. 最終受け入れ基準セクションが存在

機能要件 (3 個のチェック): 6. すべての機能要件がテスト可能(曖昧ではない) 7. すべての要件が必須優先度(推奨/可ではない) 8. 要件が番号付け(REQ-001、REQ-002 など)

技術品質 (3 個のチェック): 9. 技術的考慮事項がアーキテクチャに対応 10. 非機能要件が具体的な数値ターゲットを含む 11. リスクが具体的な緩和策を持つ(「TBD」ではない)

延期なし強制 (3 個のチェック): 12. 「スコープ外」セクションが存在しない 13. フレーズなし: 「ナイストゥハブ」「ストレッチ ゴール」「今後の作業」「ローンチ後」「時間があれば」「v2」「後のフェーズ」 14. 「可」または「推奨」の優先度レベルなし — すべてが「必須」

検証が延期チェックで失敗した場合: 延期されたアイテムを要件に昇格させるか、完全に削除することで自動修正。ユーザーに確認を求めます。

検証出力:

PRD 品質検証: 14/14 合格
  すべての必須要素が存在
  すべての要件が必須配信
  延期されたアイテムが検出されない
  品質スコア: 70/70 (優秀)

---

ステップ 5: GitHub Issue 公開

issue の本文として完全な PRD を持つ GitHub issue を作成します。

gh issue create \
  --title "{機能名} — PRD" \
  --label "PRD" \
  --body "$(cat .taskmaster/docs/prd-{feature-slug}.md)"

issue URL をキャプチャ — これが shape-spec に渡されます。

出力:

Published PRD as GitHub issue: https://github.com/{owner}/{repo}/issues/{N}

---

ステップ 6: スコープ検出 (Shape-Spec プロンプト アセンブリ用)

PRD が公開されたため、shape-spec プロンプトに含めるエンジニアリング スコープ セクションを検出します。これは PRD に影響しません — これは shape-spec が実行するで実装スタンダードを決定します。

PRD コンテンツ + リポジトリ構造から自動検出し、ユーザーに確認します。

検出ロジック:

PRD コンテンツ + リポジトリ構造をスコープ インジケーターでスキャン:

iOS インジケーター:
  - キーワード: SwiftUI、UIKit、Swift、iOS、Xcode、シミュレーター、@Observable、CoreData
  - ファイル: *.swift、<YOUR_APP>/、*.xcodeproj、*.xcworkspace

Backend インジケーター:
  - キーワード: API、endpoint、controller、.NET、Cloud Run、PostgreSQL、Redis
  - ファイル: *.cs、*.csproj、Infrastructure/、Controllers/

GCP/Infra インジケーター:
  - キーワード: Terraform、Cloud Run、Cloud SQL、deployment、CI/CD、Docker
  - ファイル: *.tf、cloudbuild.yaml、Dockerfile*、.github/workflows/

AskUserQuestion で確認:

PRD は公開されました。次に、shape-spec 実行プロンプトに含めるエンジニアリング スコープ セクションを
決定する必要があります。

PRD コンテンツに基づいて、以下を検出しました:

  [x] iOS (Swift/SwiftUI) — [検出されたインジケーター]
  [x] Backend (.NET/Cloud Run) — [検出されたインジケーター]
  [ ] GCP/Infrastructure — [検出されたもの なし]

これは正しいですか? (確認 / 調整)

確認されたスコープを SCOPE_IOS、SCOPE_BACKEND、SCOPE_GCP_INFRA として保存。

---

ステップ 7: Shape-Spec トリガー

スコープ認識型セクションで /agent-os:shape-spec プロンプトをビルドしてトリガー。これらのセクションは PRD をどのように 実装するかを shape-spec に指示します — プラットフォーム固有のエンジニアリング スタンダード、ビルド コマンド、および品質ゲート。

プロンプトは以下から構成されます:

1. ベースライン システム プロンプト (常に含まれる)
2. スコープ固有のセクション (ステップ 3 の検出に基づいて含まれる)
3. Issue URL (ステップ 6 から)

ベースライン システム プロンプト (常に含まれる)

/agent-os:shape-spec {ISSUE_URL} に PRD があります。

計画とタスク シリーズを作成します。並列化に適切なエージェントを特定します。品質管理、チェック、
および検証の監督エージェントを含めます。気に入るエージェントがない場合は、新しいエージェントを作成します。

## 実行要件

- すべてのエージェントは Opus 4.6 で実行する必要があります。例外はありません。コスト削減のダウングレードはありません。
- NO TASKS OR DELIVERABLES ARE OPTIONAL. EVER. PRD 内のすべてが必須配信です。
- 計画はできるだけワンショットで実行できるものであるべきです。第 1 段階で説明質問および/または
  前提条件をユーザーに要求/指示することができます。その後、実行は停止せずに完了まで実行されます。
- 最終 PR は受け入れ前に最終検証として '/pr-handoff-to-codex' を実行する必要があります。
  これは配信エージェントの監督の期待や期待される品質を制限しません — 追加の検証ゲートです。

## クリエイティブ リソース使用法

- あなたとエージェントはツール使用法でクリエイティブに行動する必要があります。可能な限り CLI ツールと MCP サーバーを使用します —
  常に最初に利用可能なものを確認してください(素晴らしいものがたくさんあります)。
- <YOUR_WEBSITE_URL> リソース(UI/ビジュアル作業向けの '/brand-guidelines' を含む)の利点を活用します。
- 独立したタスクの並列化に Agent ツールを使用します。
- セキュリティ関連の変更には '/security-scan' を使用します。
- パフォーマンス クリティカル コンポーネントには '/perf-check' を使用します。

## 品質スタンダード

- すべてのエージェントは、完了とマークする前に自分の作業を検証する責任があります。
- 監督エージェントは、PRD 要件に対してすべての作業をレビューします。
- テストは実装と並行して書かれる必要があります。後からではなく。
- すべてのビルドはタスク完了前に合格する必要があります。

iOS スコープ セクション (SCOPE_IOS = true の場合に含まれる)

## iOS 要件

- Swift 6 / SwiftUI (@Observable パターン付き) (iOS 17+)
- <YOUR_APP>/<YOUR_APP>/Core/Services/ および <YOUR_APP>/<YOUR_APP>/Features/ の既存パターンを従う
- ViewModels は依存関係に @ObservationIgnored を持つ @Observable マクロを使用
- ビルド検証: cd <YOUR_APP> && xcodebuild -project <YOUR_APP>.xcodeproj -scheme "<YOUR_APP> Dev" \
    -destination 'platform=iOS Simulator,name=iPhone 17 Pro Max,OS=26.2' build
- テスト検証: cd <YOUR_APP> && xcodebuild -project <YOUR_APP>.xcodeproj -scheme "<YOUR_APP> Dev" \
    -destination 'platform=iOS Simulator,name=iPhone 17 Pro Max,OS=26.2' test
- デザイン システム準拠: 新しい UI コンポーネントには '/ios-design' を使用
- '/brand-guidelines' を色、タイポグラフィ、およびビジュアル アイデンティティに使用
- CLAUDE.md パターン(SwiftUI Map、遅延サービス init、オーディオ パイプラインなど)を従う
- すべての新しいビューは iPhone および iPad スクリーン サイズで動作する必要があります
- アクセシビリティ: すべてのインタラクティブ要素に VoiceOver ラベル

Backend スコープ セクション (SCOPE_BACKEND = true の場合に含まれる)

## Backend 要件 (.NET 8 / Cloud Run)

- Infrastructure/<YOUR_API_PROJECT>/Controllers/ および Services/ の既存パターンを従う
- すべてのエンドポイントは Firebase Bearer トークン認証を使用する必要があります
- JSON レスポンスは camelCase を使用、日付は ISO 8601 を使用
- EF Core エンティティは snake_case PostgreSQL カラムにマップ
- JSONB カラムは適切なシリアライゼーションを使用した JsonDocument を使用
- 新しいエンドポイントは適切なルート属性で登録
- DI 登録は GCPStartup.cs に追加
- データベース クエリは .Select() プロジェクションを使用する必要があります — ContentVector を使用した完全なエンティティをロードしない
- 設定駆動: AI モデル名、プロンプト、生成パラメーター、または魔法の数値のハードコードなし
- ビルド検証: cd Infrastructure/<YOUR_API_PROJECT> && dotnet build <YOUR_API_PROJECT>.GCP.csproj
- テスト検証: cd Infrastructure/<YOUR_API_PROJECT>.Tests && dotnet test --filter "FullyQualifiedName!~Integration"
- 実装後に curl でエンドポイントをテスト
- エラー ハンドリング: すべての非同期呼び出しに try/catch があり、意味のあるエラー メッセージ
- セキュリティ脆弱性なし (SQL インジェクション、XSS、ハードコード シークレット)

GCP/Infrastructure スコープ セクション (SCOPE_GCP_INFRA = true の場合に含まれる)

## GCP / Infrastructure 要件

- マルチ環境対応: dev (<YOUR_GCP_PROJECT_DEV>)、staging (<YOUR_GCP_PROJECT_STAGING>)、prod (<YOUR_GCP_PROJECT_PROD>)
- Cloud Run サービス名はすべての環境で '<YOUR_SERVICE_NAME>' — 区別はプロジェクト分離から来る
- Dockerfile.gcp を常に使用 (Dockerfile ではなく)。ビルド コンテキストは Infrastructure/<YOUR_API_PROJECT>/
- Infrastructure/terraform/ の Terraform モジュール — 既存モジュール パターンを使用
- State バケット: gs://<YOUR_TF_STATE_BUCKET>-{env} (バージョニング有効)
- GitHub Actions CI/CD: WIF キーレス認証 (GCP クレデンシャルをシークレットに保存しない)
- ダイジェストによる配信: OCI ダイジェストによるクレーン コピーでイメージを昇格、タグではなく
- Cloud Logging でデバッグ: 適切な重大度レベルで構造化ロギングを使用
- Secret Manager for all secrets — ハードコード、コミットしない
- Terraform プランを適用する前に: cd Infrastructure/terraform/environments/dev && terraform plan
- Docker ビルド テスト: docker build -f Infrastructure/<YOUR_API_PROJECT>/Dockerfile.gcp -t <YOUR_SERVICE_NAME>:local Infrastructure/<YOUR_API_PROJECT>
- サービス アカウント権限: デプロイ前に必要な IAM ロールを確認
- Cloud SQL Proxy for local dev database access
- Redis/Memorystore: キャッシュ TTL と無効化パターンを確認

テスト セクション (常に含まれる、テスト ヘビーの場合に拡張)

## テスト要件

- テストは実装と並行して書かれます。後からではなく
- iOS テスト: <YOUR_APP>/Tests/ の XCTest、機能名をミラー
- Backend テスト: Infrastructure/<YOUR_API_PROJECT>.Tests/ で dotnet test
- 最小カバレッジ: すべての新しいパブリック API と重要なパス
- エッジ ケースがカバー: null、empty、境界値、エラー条件
- テスト汚染なし: 各テストは独立
- 統合テストはユニット テストから分離 (--filter "FullyQualifiedName!~Integration" でフィルター)
- パフォーマンス テスト(レイテンシー sensitive パス用) (API < 200ms p95、DB クエリ < 50ms)

パフォーマンス セクション (常に含まれる)

## パフォーマンス ターゲット

- API レスポンス時間: < 200ms p95
- PostgreSQL クエリ: < 50ms
- iOS ローンチ時間: < 2s
- メモリ使用量: < 150MB
- パフォーマンス クリティカル コンポーネントを検証するには '/perf-check' を使用

---

プロンプト アセンブリ

最終プロンプトは以下を連結して組み立てられます:

1. ベースライン システム プロンプト
2. iOS セクション (SCOPE_IOS の場合)
3. Backend セクション (SCOPE_BACKEND の場合)
4. GCP