prd-create

vfarcic/dot-ai の shared-prompts/prd-create.md を基にしています（MIT、Copyright (c) 2025 Viktor Farcic）。原著者：Viktor Farcic。スコープ設定とスライスのルールは、Matt Pocock の mattpocock/skills（MIT）のアイデアである、トレーサーバレット型の垂直スライス、ブロッキングエッジ、ディープモジュールを取り入れています。

PRD 作成スラッシュコマンド

手順

新機能のプロダクト要件定義書（PRD）の作成を支援します。このプロセスには、次の 2 つの要素があります。

1. GitHub Issue：詳細な PRD にリンクする、短く不変のコンセプト説明
2. PRD ファイル：マイルストーンの追跡と実装計画を含むプロジェクト管理ドキュメント

プロセス

ステップ 1：成果を把握する（インタビューはしない）

ユーザーの説明から、自分で成果を判断してください。インタビューは行わず、コードの書き方や構成についてユーザーに尋ねてはいけません。技術的な選択はあなたが行い、その理由とともに Decision Log に記録してください。

• 事実は調べ、尋ねないでください。 コード、ドキュメント、Issue、既存の PRD を確認してください。その機能がすでに存在するか、以前に提案されて却下されていないか（クローズ済みの Issue、prds/done/、Decision Log）をまず確認してください。
• 質問は最大 1 回にまとめてください。未解決のプロダクト意図、または選択肢によってユーザーが得るものが変わる分岐についてのみ質問します。それぞれに推奨回答を示してください。依頼内容が明確であれば質問は不要です。
• 既存のエスカレーションはこれまでどおり適用されます：外部 API コントラクトの変更、既存データに影響するスキーマ変更、認証またはセキュリティモデルの変更、取り消し不能な操作。セキュリティコードに触れるだけの作業は、デザイン批評の段階（agent-team）に回し、ユーザーには尋ねません。
• バグの PRD では、バグを示す再現シグナル（失敗するテスト、コマンド、または取得済みのトレース）を記載するか、現時点で存在しない理由を説明してください。

ステップ 1.2：スコープゲート（何かを作成する前に）

PRD Issue 1 件は、実装 1 回と PR 1 件に対応します（uzi の実行 1 回、または /prd-full のループ 1 回です。ドキュメントのみの PRD は、/prd-done に従って直接コミットして完了する場合があります）。PRD 内でマイルストーンを再構成しても、その PR の範囲は小さくなりません。範囲を小さくするのは、Issue のサイズを小さくした場合だけです。そのため、マイルストーンだけでなく Issue のサイズを決めてください。

• PRD 1 件につき、独立して価値のある成果 1 つです。 スライスが独立して役立つ場合に限り、独自の PRD を作成してください。それ以外の場合は、PRD 内のマイルストーンとしてください。
• スコープレビューの警告（分割が自動的に決まるわけではありません）：独立して価値のある成果が複数ある場合、または大規模な PR（多数のコンポーネントや長大なファイルマップ）が見込まれる場合。該当する場合は、順序を付けて独立した PRD に分割する案を、ユーザーへの 1 回の yes/no 質問として提示してください。
• 重大なエラー：未完了の PRD を必要とするマイルストーン。 そのマイルストーンを後続の PRD に移すか、境界を引き直してください。この PRD 内に保留状態で残してはいけません。
• 分割作業には、子 PRD の一覧、順序、ブロッキングエッジのみを記載するアンブレラ Issue を設けてください。 各子 PRD は、このスキルで作成する通常の PRD です。子 PRD を uzi に渡す際は、ユーザーが各子 PRD の計画ではなく分割案を一度だけ承認すればよいよう、デフォルトで Auto または Seed & ship モードを使用してください。
• 既存のオープンな PRD も、ディスパッチ前に同じスコープレビューを受けます（/prd-start が実行します）。

分割パス（ユーザーが分割を承認した場合）

1. 何かを作成する前に、Step 1.5 の次のステップとレビューに関する質問を一度だけ行い、回答（uzi モードやスイープラベルがあればそれも含む）をすべての子課題で再利用します。
2. 親課題を作成します。PRD ラベルもスイープラベルも付けない通常の課題です。本文では、ブロッキング関係とともに子課題の成果を順番に列挙します。マイルストーンは設定しません。
3. 各子課題について、依存関係の順に、Step 2～5 を通常の PRD として実行します（それぞれ独自の課題に PRD ラベルを付け、独自の prds/ ファイルを作成します）。その後、各子課題へのリンクを親課題に追加します。
4. ブロッカーが完了している子課題にのみ、選択した次のステップを適用します。未完了のブロッカーがある子課題については、コミットしてプッシュするだけで、それ以外は行いません。作業の開始、uzi への送信、スイープラベルの付与は行いません。後でブロッカーが解消された際は、記録済みの選択を一度だけ適用して有効化します。

Step 1.5：PRD 作成後のワークフローを事前に確認する（何かを作成する前に）

課題または PRD を作成する前に、uzi が利用可能かどうかを確認します（command -v uzi が成功する、または uzi-cli スキルが ~/.claude/skills/uzi-cli/ にインストールされている）。uzi が利用可能な場合は、uzi schedule list --json も一度実行して、スイープスケジュールが存在するかどうかと、そのラベルを確認します。これにより、以下の「コミットしてプッシュし、uzi スイープに登録」オプションを提示するかどうかと、ラベルの選択肢が決まります。その後、PRD 作成中に中断が入らないよう、後続の選択をすべて続けて確認します。

1. AskUserQuestion（次のステップ＋レビュー）：2 つの質問を含むプロンプトを 1 つ提示します。
   • 次のステップ：Start working now、Commit & push for later、そしてuzi が検出された場合のみ、Commit & push + queue for uzi sweep と Send to uzi を提示します（uzi がない場合は 2 つ、ある場合は最大 4 つの選択肢です）。Commit & push + queue for uzi sweep は後回しにする引き継ぎです（オプション 4 を参照）。Commit & push for later と同様にコミットしてプッシュした後、uzi のスイープスケジュールが後で実行するよう課題にラベルを付けます。今すぐ実行を開始することはありません。Commit & push + queue for uzi sweep は、uzi が検出され、かつ uzi schedule list --json で 1 つ以上のスイープスケジュールが報告された場合にのみ提示します。
   • PRD のレビュー：No review、One reviewer、または Let the skill decide（スキルが PRD の規模と複雑さに応じて人数を選択します）。ユーザーは「その他」を選び、正確な人数を指定できます。
2. 最初のプロンプトの直後、かつ PRD の作成前に、必要な場合は 2 つ目の AskUserQuestion をすぐに提示します（PRD 作成後まで先送りしないでください）。
   • ユーザーが Send to uzi を選択した場合：uzi のモードを確認します。uzi-cli スキルを読み込み、その Send to uzi メニュー（Auto / Supervised / Seed & ship / Custom）を使用します。
   • ユーザーが Commit & push + queue for uzi sweep を選択し、かつ uzi schedule list --json で複数のスイープスケジュールが示された場合：登録先のスイープラベルを確認します（例：Night、bug）。スイープが 1 つだけの場合はそれを使用し、質問はしません。

回答はすべて保持し、PRD の作成後に適用します。まずレビューを実行し、その後に選択された次のステップを実行します（Send to uzi の場合は、ここで選択済みのモードを使い、再度質問しません）。最後に番号付きのメニューを提示しないでください。対話的に実行できない場合（質問できるユーザーがいない場合）は、Commit & push for later と No review を既定値にします。

次のステップとして Send to uzi または Commit & push + queue for uzi sweep が選択された場合、PRD はオフラインで作業する担当者が単独で作業できる内容にする必要があります（どちらの場合も PRD は uzi ワーカーに引き渡されます。スイープのオプションでは、即時実行ではなくスケジュールされたスイープを通じて引き渡されます）。uzi ワーカーの外部通信は制限されています。フォージ、*.anthropic.com、パッケージキャッシュには接続できますが、オープンウェブには接続できません（任意の GitHub、外部ドキュメントサイト、WebFetch／WebSearch は利用できません）。そのため、インターネットを必要とする調査は実行できません。PRD の作成時（Step 5）に、インターネット接続が必要な調査をすべて事前にローカルで行い、その調査結果を確定済みの事実として PRD 本文に記載してください。「実装担当者がオンラインで X を確認する」といったマイルストーンを残してはいけません。Step 5 のコールアウトを参照してください。

ステップ 2：まず GitHub Issue を作成する

Issue ID を取得するため、直ちに GitHub Issue を作成します。この ID は、PRD ファイルに適切な名前を付けるために必要です。

重要：Issue に「PRD」ラベルを追加して、見つけやすくしてください。

ステップ 3：正しい命名規則で PRD ファイルを作成する

実際の GitHub Issue ID を使って、PRD ファイルを作成します：prds/[issue-id]-[feature-name].md

ステップ 4：GitHub Issue に PRD のリンクを追加する

ファイル名がわかったら、PRD ファイルへのリンクを GitHub Issue の説明に追加します。

ステップ 5：プロジェクト管理ドキュメントとして PRD を作成する

PRD テンプレートに沿って、プロジェクト管理、マイルストーンの追跡、実装計画を中心に進めます。ドキュメントの更新も、実装マイルストーンの一部として含めてください。

🔴 Send to uzi または Commit & push + queue for uzi sweep を選択した場合（ステップ 1.5）、インターネット依存の調査を今すぐ PRD 本文で解決してください。 uzi ワーカーはオープンウェブにアクセスできません（egress は forge、*.anthropic.com、パッケージキャッシュのみに制限されています）。マイルストーンが依存する情報のうち、オープンインターネットからしか得られないもの（外部 API やライブラリの仕様、クローンではなく閲覧が必要な上流ソース、ドキュメントページ、ウェブ検索、CVE の照会など）は、ワーカーには調べられません。そのため、マイルストーンが停滞したり、ワーカーが推測したりすることになります。引き継ぐ前に、次の対応を行ってください。

• 自分で調査し、回答をタスクではなく、出典付きの明示的な事実として PRD に記載してください。「widget API がレート制限されているか確認する」を、「widget API は <link> によると 1 分あたり N 回にレート制限されているため、M2 ではバックオフが必要である」に変えます。
• オフラインで解決できる方法がある場合は、そちらを優先してください。 外部の調査より、プロダクト自身のデータやログからの実測値、またはコードベースの確認を優先します。こうすれば、ワーカーが egress なしで再検証できます。こうした確認は、マイルストーン内でオフラインで実施することを明記してください。
• 重要な事実を確定するためにインターネットが本当に必要な場合は、送信前に自分で確定してください。そうしなければ、PRD を uzi に渡す準備が整っていません。 解決できなかったものがあれば、インターネット依存のまま暗黙に進むマイルストーンを出すのではなく、その点を明記してください。

PRD ファイルのセクション

以下は prds/ ファイルのセクションです。後述の「GitHub Issue Template」は短い Issue 本文のみを指し、PRD ファイルではありません。

1. 問題：誰が、ユーザーの視点からどのように問題に直面するのか。
2. 成果：この PRD の完了時に何が機能するのか、および具体的な受け入れ例を 2～3 件（入力、操作、観察可能な結果）示します。ユーザーはこれを読むだけで異議を申し立てられます。
3. 対象外：後続の PRD に移すものも含め、この PRD では意図的に対応しないもの。
4. モジュールと接続点：重要なものに限ります。それぞれについて、呼び出し元に公開するインターフェース（入力、出力、不変条件、エラー時の動作）、隠蔽する複雑さ、テストで検証する場所を記載します。既存の接続点とインターフェースを優先し、必要性が実証された場合にのみ新しいものを追加してください。
   • 信頼できない入力を受け取るモジュールでは、リソースの上限を明示します。 呼び出し元が消費できるリソース（保存バイト数、展開後のメモリ、データベース接続数と並列実行数、バックグラウンド処理、経過時間）ごとに、上限とその適用箇所を示します。別の所有者に影響する取り消し不能な処理（削除、再利用、課金）は、検証前の宣言値に基づいて行ってはなりません。
   • 既存コンポーネントの安全性に関する仕組み（クローンのパス、アップロードのパターン、リミッターなど）を再利用する場合、従来受け入れられていたリスクが、この PRD の呼び出し元に対しても妥当かを明記します。管理者が制御する入力で受け入れられていたリスクを、ユーザーやプロダクトが制御する入力にそのまま適用してはなりません。
5. テスト方針：どの動作をどの接続点でテストするか、および参考にする既存の類似テスト。
6. マイルストーン：以下のルールに従った、垂直スライス。
7. 決定ログ：理由と採用しなかった代替案を含む、技術的な決定すべて。

デザインモック

機能にユーザー提供または作成時に用意したモック（HTML ページ、TUI スクリプト、画像）がある場合：

• PRD と一緒に prds/mockups/[issue-id]-[feature-name].[ext] にコミットします。実装者やオフラインの uzi ワーカーが見られるのはリポジトリ内のものだけです。ユーザーのモックがリポジトリの外にある場合は、コミットを一度だけ依頼します。断られた場合は、代わりに PRD の本文でデザインを説明します。
• PRD の冒頭にリンク（**Design mock**: <path> と、表示方法）を記載し、次の取り決めを PRD に明記します。
  • モックは、レイアウト、列、順序、グリフ、色の役割、キー、文言に関するプレゼンテーションの参照元です。テキスト仕様だけでなく、モックも実装します。
  • アプリとの一貫性を保つための小さな差異は許容されます。たとえば、アプリのパレットトークン、文言、コンポーネント、間隔に合わせた変更です。
  • より大きな差異（要素の削除、レイアウト、ナビゲーション、情報の変更）は必要な場合に限り、理由とともに PR 本文の Mock deviations に記載します。この一覧がない場合は、モックとの一致を表明したものとみなします。
  • 検証では、モックと並べて（スクリーンショットまたはリポジトリのレンダリングハーネスで）結果を比較し、その証拠を PR に添付します。
• 優先順位を明記します。仕様を記載している箇所では PRD の本文が優先され、本文で触れていない部分はモックが基準になります。
• モック UI を描画する各マイルストーンの受け入れ基準に、モックとの一致を含めます。

マイルストーンは垂直スライスです

• 各マイルストーンは、それ単独で検証できる完全な振る舞いとし、必要なすべてのレイヤー（スキーマ、ロジック、API、UI、テスト、ドキュメント）にまたがるものにします。新規の実装を一度実行するだけで、ビルドと検証ができなければなりません。
• 単独のレイヤーをマイルストーンにしてはいけません。「スキーマ」「サービスレイヤー」「テスト」「ドキュメント」のように、後続のマイルストーンの準備だけを行うものは設けません。テストとドキュメントは、それらが対象とするスライスに含めます。
• 各マイルストーンに Blocked by（実際に依存するマイルストーンのみ、または「none」）と受け入れ基準を記載します。
• 先にプレファクターします。 リファクタリングによって機能の実装が容易になる場合は、それを最初のマイルストーンにします。
• 広範なリファクタリングは例外です。 コードベース全体に影響する機械的な変更（名称変更、型の変更）は、拡張してから縮小する手順で進めます。新しい形式を古い形式と並行して追加し、呼び出し側を一括で移行してから、古い形式を削除します。
• マイグレーションは、それを必要とする最初のスライスに含めます。
• マージされた各スライスは単独で安全でなければなりません。セキュリティ要件を満たすか、デフォルトで無効のフラグの背後に置きます。ただしその場合は、到達可能なすべてのエントリーポイントでフラグを確認し、無効時のマイグレーションが既存のデータと動作を変更しないことが条件です。
• マイルストーン数は固定しません。 数ではなく、スコープゲート（ステップ 1.2）に基づいて規模を決めます。

例（「ユーザーがレッスンを完了するとポイントを獲得する」場合のレイヤー別と垂直スライス）：

• ❌ M1 スキーマ；M2 ポイントサービス；M3 ダッシュボードウィジェット；M4 テスト
• ✅ M1 レッスンを完了するとポイントが付与され、ダッシュボードに合計が表示される（スキーマ、サービス、ウィジェット、テスト）；M2 連続達成で付与ポイントが増え、ダッシュボードにも表示される（M1 が完了条件）；M3 過去の完了分のポイントを補完する（M1 が完了条件）

並列作業

ブロッカーが解消されたマイルストーンは、並列作業の候補であり、並列作業が保証されるわけではありません。担当するファイルと状態が互いに独立している場合に限り、2 つを並行して進めます。それ以外の場合は順番に進めます。リード担当者が統合し、統合後のツリーでゲートを実行します。また、リポジトリで必要な場合はマイグレーション番号を振り直します。

受け入れはマイルストーンではありません

PRD は、そのコードがマージされた時点で完了です（ドキュメントのみの PRD は、/prd-done に従ってドキュメントの変更が反映された時点で完了です）。機能の振る舞いを確認できるのがライブ環境のみの場合（クラスター、ネットワークポリシー、外部サービスなど）は、ライブ環境でのチェックリストを記載した関連付け済みの acceptance イシューを作成し、期限を設けず、担当者をユーザーに設定します。また、uzi の一括処理ラベルは付けません。これはマージやクローズの妨げにはなりません。後続の PRD でこのイシューを参照し、ユーザーがライブ環境での動作確認を必要と判断した場合に限り、そのイシューを完了条件にします。

GitHub Issue テンプレート（短く、安定した内容にする）

Issue の初回作成（PRD へのリンクなし）：

## PRD: [Feature Name]

**Problem**: [1-2 sentence problem description]

**Solution**: [1-2 sentence solution overview]

**Detailed PRD**: Will be added after PRD file creation

**Priority**: [High/Medium/Low]

作成後、Issue に「PRD」ラベルを追加するのを忘れないでください。

Issue の更新（PRD ファイルの作成後）：

## PRD: [Feature Name]

**Problem**: [1-2 sentence problem description]

**Solution**: [1-2 sentence solution overview]

**Detailed PRD**: See [prds/[actual-issue-id]-[feature-name].md]([repo-web-url][forge-file-path]prds/[actual-issue-id]-[feature-name].md)

**Priority**: [High/Medium/Low]

PRD の作成に取り組む

コードとコンテキストから、以下の項目を自分で回答してください。これは作成者向けのチェックリストであり、ユーザーへの質問ではありません（ステップ 1 を参照）。

• 問題と成果：誰に影響があり、その人にどのような変化が観察できるか。
• 既存の取り組み：すでに存在するか、一部だけ存在するか、それとも以前に却下されたか。
• 境界：この機能がまたぐインターフェースと、テストされる場所。
• リスクと依存関係：何が壊れる可能性があるか、この機能に他のシステムから何が必要か、また依存関係に未完了の PRD が含まれていないか（スコープゲートのエラー）。
• スライス：アプローチを実証する最小のエンドツーエンドの動作と、それを拡張するスライス。
• 必須事項とあれば望ましい事項：あれば望ましい事項は「スコープ外」または後続の PRD に記載します。

Forge に依存しない手順：以下の gh コマンドは GitHub の例です。git remote get-url origin で forge を判別し、各動詞を対応するコマンドに置き換えてください。GitHub → gh、GitLab → glab（PR は マージリクエスト、glab mr …）、Forgejo/Gitea → tea。必要な CLI がインストールされていない場合は、ユーザーに伝えてインストールページへのリンクを提示してください。[repo-web-url] は同じリモートから作成します（.git を削除し、SSH 形式の git@host:org/repo は https://host/org/repo に変換します）。[default-branch] はリモートの HEAD から取得します。ファイルパスのセグメントは forge によって異なります。GitHub は /blob/<branch>/、GitLab は /-/blob/<branch>/、Forgejo/Gitea（Codeberg を含む）は /src/branch/<branch>/ です。

注：GitHub Issue の作成時に「PRD」ラベルが存在しないため失敗した場合は、まずラベルを作成し（gh label create "PRD" --description "Product Requirements Document" --color 0052CC）、その後 Issue の作成を再試行してください。

ワークフロー

1. コンセプトの検討：基本的なアイデアを確認し、必要性を検証します
2. GitHub Issue を先に作成：Issue ID を取得するため、簡潔で安定したコンセプトの説明を記載します
3. PRD ファイルを作成：実際の Issue ID を使って、詳細なドキュメントを作成します。prds/[issue-id]-[feature-name].md
4. GitHub Issue を更新：ファイル名が確定したら、PRD ファイルへのリンクを追加します
5. 各セクションを記述：PRD ファイルの各セクションを自分で埋めます（「PRD の作成に取り組む」を参照）
6. マイルストーンを定義：Blocked by の依存関係と受け入れ基準を含む垂直スライスを定義します。PRD の範囲は件数ではなく、スコープゲート（ステップ 1.2）によって定めます
7. レビューと検証：完全性と明確さを確認します

重要：Issue ID がファイル名に必要となる鶏と卵の問題を避けるため、ステップ 2～4 は必ずこの順序で実行してください。

ROADMAP.md を更新する（存在する場合）

PRD の作成後、docs/ROADMAP.md が存在するか確認します。存在する場合は、PRD の優先度に応じた適切な期間のセクションに新機能を追加してください。

• 優先度：高 → 短期セクション
• 優先度：中 → 中期セクション
• 優先度：低 → 長期セクション

形式：- [Brief feature description] (PRD #[issue-id])

ROADMAP.md の更新は、ワークフローの最後のコミットに含めます（オプション 2）。

PRD 作成後：レビューし、選択された次のステップを実行する

次のステップとPRD レビューの選択は、作成作業に入る前に（ステップ 1.5、AskUserQuestion 経由で）確認済みです。PRD ファイルと Issue が作成されたら、順番に対応してください。レビューがリクエストされている場合は、まずレビューを実施してから、選択された次のステップを実行します。確認内容を提示してください。

✅ PRD Created Successfully!

**PRD File**: prds/[issue-id]-[feature-name].md
**Issue**: #[issue-id]

PRD レビュー（依頼された場合）

ユーザーがレビューを依頼した場合は、Agent ツール（subagent_type: Explore または general-purpose）でレビューエージェントを起動し、prds/[issue-id]-[feature-name].md を読んで、以下の観点から批評してもらいます。スコープ（独立して価値のある成果が1つであること。未完成の PRD を必要とするマイルストーンがないこと）、垂直スライス（単独のレイヤー単位のマイルストーンがないこと、実際の Blocked by エッジがあること、各スライスが1回の新しい実行に収まること）、指定された接合点でのテスト可能性、信頼できない入力、リソース上限、取り消し不能な所有者間アクションの前に宣言値を検証すること、再利用される安全性に関するストーリー（モジュールと接合点）、契約を含むコミット済みのモック（デザインモック）、明確さ、不足しているリスクと依存関係。リポジトリにエージェントチームの architect ロールがある場合は、レビュー担当者の1人にします。

• レビュー担当者1人：エージェントを1つ起動します。
• スキルに判断を任せる：PRD の規模と複雑さに基づいて人数を選びます。小規模で単一コンポーネントの PRD なら1人、大規模または複数コンポーネントにまたがる PRD なら2～3人とし、各エージェントに異なる観点（スコープ／実現可能性、マイルストーン／テスト可能性、リスク／依存関係）を担当させます。並列で実行します。
• 具体的な人数：指定された人数ちょうどのエージェントを起動し、観点を分担させます。

指摘事項を集めてユーザーに提示し、ユーザーが承認した修正を PRD ファイルに適用します。その後、以下で選択された次の手順に進みます。

オプション1：今すぐ作業を開始する

ユーザーが今すぐ作業を開始するを選んだ場合は、まず PRD をコミットしてプッシュします（後でコミット＆プッシュと同じ）。その後、次のように案内します。

---

PRD をコミットしてプッシュしました。

この PRD の作業を開始するには、/prd-start [issue-id] を実行してください。

---

オプション2：後でコミット＆プッシュする

ユーザーが後でコミット＆プッシュを選んだ場合：

PRD は PR やフィーチャーブランチを使わず、直接 main にコミットしてください。 これはデフォルトブランチで先にブランチを作成するルールより優先されます。ブランチと PR は PRD ファイルではなく、prd-start による実装に使用します。

# Stage the PRD file (plus its mock and ROADMAP.md when present)
git add prds/[issue-id]-[feature-name].md
# git add prds/mockups/[issue-id]-[feature-name].[ext]
# If docs/ROADMAP.md exists and was updated, include it:
# git add docs/ROADMAP.md

# Commit with skip CI flag to avoid unnecessary CI runs
git commit -m "docs(prd-[issue-id]): create PRD #[issue-id] - [feature-name] [skip ci]

- Created PRD for [brief feature description]
- Defined [X] major milestones
- Documented problem, solution, and success criteria
- Added to ROADMAP.md ([timeframe] section)
- Ready for implementation"

# Pull latest and push to main
git pull --rebase origin main && git push origin main

確認メッセージ：

✅ PRD committed and pushed to main

The PRD is now available in the repository. To start working on it later, execute:
prd-start [issue-id]

オプション 3：uzi に送信する（uzi-cli スキルに引き継ぐ）

uzi が利用可能な場合にのみ、このオプションを提示してください（command -v uzi が成功するか、uzi-cli スキルがインストールされている場合）。ここで uzi のフローを再実装しないでください。新しく作成した PRD を、uzi-cli スキルの Send to uzi オーケストレーションに引き継ぎ、Step 1.5 で最初に選択したモード（Auto／Supervised／Seed & ship／Custom）を使用して、そこから実行を進めてください。

0. 事前確認：PRD はインターネットに依存しない内容である必要があります。 ワーカーはオープンウェブへの外部接続ができないため（Step 5 の注意書きを参照）、完了にオープンインターネットが必要なマイルストーンがないか PRD を再確認し、該当する内容を本文で解決してください。重要な外部情報が未解決のままであれば、今すぐ解決するか、PRD はまだ uzi に渡せる状態ではないとユーザーに伝えてください。
1. まず PRD をコミットしてプッシュします（オプション 2 とまったく同じ手順）。これにより、issue と prds/ ファイルがリモートに置かれ、uzi ワーカーがクローンできるようになります。seeded パス用にプッシュしたコミットを記録します：PRD_SHA=$(git rev-parse HEAD)。
2. uzi がこのリポジトリを追跡していることを確認します。 まだ読み込まれていなければ uzi-cli スキルを読み込み（Skill ツール）、次に uzi repo list --json を実行してリポジトリの id を確認します。リポジトリが一覧にない場合、uzi に登録されていないことをユーザーに伝え、オプション 2 に切り替えてください。
3. uzi-cli スキルの Send to uzi セクションに引き継ぎます。この PRD の情報として、リポジトリの id、issue #[issue-id]、および seeded 実行の場合は --planned-commit "$PRD_SHA" を渡してください。Step 1.5 で最初に選択したモードを使用します。
   • Auto／Supervised／uzi に計画させる：uzi はプッシュ済みの PRD issue から計画するため、ローカルで計画を作成する必要はありません。
   • Seed & ship：PRD のマイルストーンと技術的な範囲に基づいてローカルで計画を作成し（ガイドとして uzi-cli の Authoring a seeded plan セクションを使用）、その後 seed します。
4. このスキルが PRD ラベルを付けたにもかかわらず、uzi が PRD ラベルの不足を理由に issue を拒否した場合は、ポーラーがまだ同期していません。forge の Promote アクションを issue に対して使用してください（ラベルを書き込み、uzi のキャッシュを 1 回のリクエストで更新します）。その後、再試行してください。

インストール済みの uzi-cli スキルが Send to uzi セクションより古い（古い uzi バイナリを使用している）場合は、seeded パスでは Authoring a seeded plan セクションに切り替えるか、ゲート付きパスでは uzi run create --repo <id> --issue [issue-id] を実行してください。

オプション 4：コミットしてプッシュし、uzi のスイープに登録する

uzi が利用可能で、かつ uzi schedule list --json が少なくとも 1 つのスイープスケジュールを報告した場合にのみ、このオプションを提示してください。 これはオプション 2 の 後回しにする 形式です。今すぐ実行を開始する Send to uzi とは異なり、PRD をコミットしてプッシュし、issue にラベルを付けて、uzi の スイープスケジュール が独自の周期（たとえば毎晩のスイープ）で実装するようにします。ここでは実行は開始されません。

0. 事前確認：PRD はインターネットに依存しない内容である必要があります（オプション 3 と同様、スイープはオフラインのワーカーで実行されます）。PRD を再確認し、オープンウェブへの依存があれば本文で解決してください。重要な外部情報が未解決の場合は解決するか、まだ準備ができていないとユーザーに伝えてください。
1. まず PRD をコミットしてプッシュします（オプション 2 とまったく同じ手順）。スイープが実行される前に、issue と prds/ ファイルがリモートに置かれるようにします。
2. スイープラベルを特定します。ハードコードしてはいけません。 Step 1.5 で取得した uzi schedule list --json の内容から、対象／種別が sweep のスケジュールを選び、その labels を確認します。
   • スイープが 1 つだけの場合 → そのラベルを使用します。
   • 複数ある場合（例：Night、bug）→ Step 1.5 で最初に選択したラベルを使用します。
   • ない場合 → 登録対象がないため、オプション 2 に切り替え、その旨を伝えてください。
3. このリポジトリで検出済みの forge CLI（glab／gh／tea）を使って issue にラベルを付けます。このスキルが追加した PRD ラベルは維持してください。GitLab の例：

   glab issue update [issue-id] --label "[sweep-label]"
   

4. 実行を開始しないでください。 PRD がプッシュ済みで、issue に [sweep-label] スイープ用のラベルが付いており、スケジュールに従って処理されることをユーザーに伝えてください。

ここでは uzi バイナリを直接実行します（オプション 3 の uzi repo list --json と同様）。uzi-cli スキルを読み込む必要はなく、ラベル名がこのスキルに埋め込まれることもありません。

重要な注意事項

• オプション 1：すぐに実装を始める時間がある場合に最適です
• オプション 2：複数の PRD を作成する場合や、今後の作業を計画する場合に最適です
• オプション 3（uzi に送信）：PRD を uzi-cli スキルの uzi に送信 メニューに渡します。このメニューでは、自動化の度合い（自動／監督付き／種をまいてリリース／uzi に計画を任せる）を選択し、予算上のトレードオフを説明します。種をまく実行では uzi のグローバルなデフォルト予算が使われます（計画は小規模に保ちます）。一方、ゲート付きの経路では、uzi が確定するマイルストーンに合わせて予算が拡大します（大規模な PRD や複数コンポーネントにまたがる PRD に適しています）。
• オプション 4（uzi のスイープにキュー登録）：オプション 2 の後回しにする版です。PRD をコミットしてプッシュし、uzi の スイープスケジュール 用のラベルを issue に付けます（ラベルは実行時に uzi schedule list --json で検出し、ハードコードしません）。これにより、今は実行を開始せず、後のスケジュール済みスイープで実装されます。uzi が検出され、スイープスケジュールが存在する場合のみ表示されます。
• PRD 用の PR は作成しない：main に直接コミットします（オプション 1／2）。機能ブランチや PR は使いません。これは一般的な「ブランチを先に作成する」ルールの例外です。ブランチや PR を使うのは prd-start の実装です。
• CI スキップフラグ：PRD のみの変更をコミットするときは、必ず [skip ci] を使用します
• issue の参照：追跡可能性を確保するため、コミットメッセージに issue 番号を含めます