to-prd

このスキルは、現在の会話内容とコードベースの理解を踏まえて PRD を作成します。ユーザーにインタビューしないでください — 既に知っていることを統合するだけです。

issue tracker とトリアージラベルの用語集があなたに提供されているはずです — ない場合は /setup-matt-pocock-skills を実行してください。

プロセス

1. 必要に応じてリポジトリを探索し、コードベースの現在の状態を理解します。PRD 全体を通じてプロジェクトのドメイン用語集を使用し、対象領域の ADR を尊重します。

2. 実装を完了するために構築または修正する必要がある主要なモジュールをスケッチします。分離してテストできる深いモジュールを抽出する機会を積極的に探します。

深いモジュール（浅いモジュールではなく）とは、多くの機能をシンプルでテスト可能なインターフェースにカプセル化し、めったに変わらないものです。

これらのモジュールがユーザーの期待と一致していることを確認します。どのモジュールに対してテストを作成したいかをユーザーに確認します。

3. 下記のテンプレートを使用して PRD を作成し、プロジェクトの issue tracker に公開します。ready-for-agent トリアージラベルを適用します — 追加のトリアージは不要です。

<prd-template>

問題ステートメント

ユーザーが直面している問題を、ユーザーの視点から説明します。

ソリューション

その問題への解決策を、ユーザーの視点から説明します。

ユーザーストーリー

ユーザーストーリーの長い番号付きリスト。各ユーザーストーリーは以下の形式である必要があります：

1. As an <actor>, I want a <feature>, so that <benefit>

<user-story-example> 1. As a mobile bank customer, I want to see balance on my accounts, so that I can make better informed decisions about my spending </user-story-example>

このユーザーストーリーのリストは非常に広範で、機能のすべての側面をカバーする必要があります。

実装決定事項

行われた実装決定事項のリスト。以下を含めることができます：

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

特定のファイルパスやコードスニペットは含めないでください。すぐに陳腐化する可能性があります。

例外：プロトタイプが散文よりもより正確に決定をエンコードするスニペット（ステートマシン、リデューサー、スキーマ、型の形状）を生成した場合、関連する決定内にインライン化し、それがプロトタイプからのものであることを簡潔に記載します。決定に富んだ部分にトリミングしてください — 実装例ではなく、重要な部分だけです。

テスト決定事項

行われたテスト決定事項のリスト。以下を含めます：

• 良いテストとは何か（外部動作だけをテストし、実装詳細はテストしない）
• テストされるモジュール
• テストの先例（つまり、コードベース内の類似するテストのタイプ）

スコープ外

この PRD のスコープ外である事項の説明。

その他の注記

機能に関するその他の注記。

</prd-template>