write-a-prd

このスキルは PRD を作成し、./docs/<feature-name>/PRD.md に保存します。コンテキストがすでに提供されている場合や、不要だと判断した場合は、手順を省略してもかまいません。

対話形式で呼び出された場合（ユーザーがキーボードの前にいる場合）

1. 解決したい問題と、解決策として考えられる案について、ユーザーに詳しく説明してもらいます。

2. リポジトリを調査して、ユーザーの主張を確認し、コードベースの現状を把握します。

3. 共通認識に達するまで、計画のあらゆる側面についてユーザーに徹底的に質問します。設計の各分岐を一つずつたどり、決定間の依存関係を解決します。

4. 実装を完了するために、構築または変更が必要となる主要なモジュールを大まかにまとめます。単独でテストできる深いモジュールを抽出できる機会を積極的に探します。

深いモジュールとは、浅いモジュールとは対照的に、シンプルでテストしやすく、変更がほとんど発生しないインターフェースを備え、多くの機能をカプセル化したモジュールです。

これらのモジュールがユーザーの期待に沿っているか確認します。どのモジュールにテストを作成するかも、ユーザーに確認します。

5. 問題と解決策を完全に把握したら、以下のテンプレートを使って PRD を作成します。

afk から呼び出された場合（コンテキストが提供されており、ユーザーとのやり取りがない場合）

[GRILL_SUMMARY]、[ROADMAP_ENTRY]、または類似のコンテキストブロックとともに呼び出された場合は、インタビュー（手順 1～3）を省略し、提供されたコンテキストから直接 PRD を作成します。追加の質問はしないでください。ロードマップの項目またはコンテキストから機能名を推測し、小文字とハイフンを使ったスラッグにして、出力パスに使用します。

出力

PRD を ./docs/<feature-name>/PRD.md に書き込みます。必要に応じてディレクトリを作成してください。

自動ツールで抽出できるように、PRD の内容を区切り文字で囲みます。

(PRD content here)

問題の概要

ユーザーの視点から見た、ユーザーが直面している問題。

解決策

ユーザーの視点から見た、問題の解決策。

ユーザーストーリー

長く、番号付きのユーザーストーリーのリストです。各ユーザーストーリーは、次の形式にします。

1. <アクター>として、<機能>を利用したい。そうすれば、<メリット>が得られる。

1. モバイルバンキングの顧客として、自分の口座残高を確認したい。そうすれば、支出についてより十分な情報に基づいて判断できる。

このユーザーストーリーのリストは非常に網羅的なものにし、機能のあらゆる側面を扱ってください。後続のツールがストーリーを番号で参照するため、必ず番号付き項目（1.、2.、3.）を使用します。

実装上の決定事項

決定した実装上の事項をリストにします。以下を含めることができます。

• 構築または変更するモジュール
• 変更するモジュールのインターフェース
• 開発者からの技術的な補足
• アーキテクチャ上の決定
• スキーマの変更
• API コントラクト
• 具体的なインタラクション

具体的なファイルパスやコードスニペットは含めないでください。すぐに古くなる可能性があります。

テストに関する決定事項

決定したテスト方針をリストにします。以下を含めてください。

• 優れたテストの条件（実装の詳細ではなく、外部から見える振る舞いのみをテストすること）
• テスト対象のモジュール
• テストの参考となる、コードベース内の類似テスト

対象外

この PRD の対象外となる項目の説明。

補足事項

機能に関するその他の補足事項。