to-prd について
to-prdは会話の文脈とコードベースの理解をもとに、プロダクト要件定義書を作成し、プロジェクトの課題トラッカーに登録します。質問形式の聞き取りを行わず、ユーザーストーリーや実装・テスト方針をまとめたいチーム向けです。
主な機能
- 01文脈を要件定義書に集約
- 02開発・変更対象のモジュールを整理
- 03詳細なユーザーストーリーを作成
- 04実装・テスト方針を記録
- 05needs-triageラベル付きで登録
活用シーン
- 01機能の議論を要件定義書に整理
- 02ユーザーストーリーとテスト範囲を計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ camacho/ ai-skills --skill to-prdインストール後、Claude Code で/to-prdを入力して読み込まれたか確認します。
詳細
このスキルは、現在の会話のコンテキストとコードベースに関する理解をもとに、PRDを作成します。ユーザーに質問してはいけません。すでに把握している情報だけをまとめてください。
課題トラッカーには gh からアクセスできる必要があります。ラベルの語彙が必要な場合は、プロジェクトの AGENTS.md または課題テンプレートを確認してください。
プロセス
-
まだ確認していない場合は、リポジトリを調べてコードベースの現状を把握します。PRD全体でプロジェクトのドメイン用語集の語彙を使用し、変更する領域に関するADRを遵守してください。
-
実装を完了するために構築または変更が必要な主なモジュールを洗い出します。単独でテストできる深いモジュールを抽出できる機会を積極的に探してください。
深いモジュールとは、浅いモジュールとは異なり、多くの機能をシンプルでテスト可能なインターフェースにカプセル化し、そのインターフェースがほとんど変更されないモジュールです。
これらのモジュールが期待に合っているか、ユーザーに確認します。どのモジュールのテストを作成したいかもユーザーに確認します。
- 以下のテンプレートを使ってPRDを作成し、プロジェクトの課題トラッカーに公開します。通常のトリアージフローに入るよう、
needs-triageトリアージラベルを付けてください。
問題の説明
ユーザーの視点から見た、ユーザーが直面している問題です。
解決策
ユーザーの視点から見た、問題の解決策です。
ユーザーストーリー
長く、番号付きのユーザーストーリーのリストです。各ユーザーストーリーは、次の形式にしてください。
- <利用者>として、<機能>を実現したい。それにより、<メリット>が得られる
このユーザーストーリーのリストは非常に網羅的なものとし、機能のあらゆる側面をカバーしてください。
実装上の決定事項
決定した実装上の事項を列挙します。以下を含めることができます。
- 構築または変更するモジュール
- 変更するモジュールのインターフェース
- 開発者による技術的な明確化
- アーキテクチャ上の決定
- スキーマの変更
- APIコントラクト
- 具体的なやり取り
具体的なファイルパスやコードスニペットは含めないでください。すぐに古くなる可能性があります。
テスト上の決定事項
決定したテスト上の事項を列挙します。以下を含めてください。
- 優れたテストの条件(実装の詳細ではなく、外部から見た振る舞いのみをテストすること)
- テスト対象となるモジュール
- テストの先例(コードベース内にある、同様の種類のテストなど)
対象外
このPRDの対象外となる事項を説明します。
補足事項
この機能に関する補足事項を記載します。