mcpField
W
write-a-prd

write-a-prd

github.com/mattpocock開発229283 回インストール30 週間前に更新
リポジトリ

write-a-prd について

write-a-prd は、開発者が製品要件ドキュメントを作成するためのスキルです。課題の確認、リポジトリの調査、設計の議論を進め、合意した内容をローカルの Markdown ファイルにまとめます。

主な機能

  1. 01課題やアイデアについてのヒアリング
  2. 02リポジトリの現状確認
  3. 03設計上の判断を順に整理
  4. 04構築・変更するモジュールの整理
  5. 05テンプレートに沿った PRD 作成

活用シーン

  1. 01新機能の要件と解決策の定義
  2. 02変更が必要なコードモジュールの計画
  3. 03ユーザーストーリーや実装・テスト判断の記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mattpocock/ai-engineer-workshop-2026-project --skill write-a-prd

インストール後、Claude Code で/write-a-prdを入力して読み込まれたか確認します。

詳細

このスキルは、ユーザーが PRD の作成を希望したときに呼び出されます。必要ないと判断した手順は省略してもかまいません。

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

  2. リポジトリを調べ、ユーザーの主張を検証するとともに、コードベースの現状を把握します。

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

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

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

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

  1. 問題と解決策を完全に理解したら、以下のテンプレートを使用して PRD を作成します。PRD は issues/prd.md にローカルの Markdown ファイルとして作成します。issues/ ディレクトリが存在しない場合は作成します。GitHub issue の作成や外部サービスの呼び出しは絶対に行わないでください。

問題の説明

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

解決策

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

ユーザーストーリー

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

  1. <利用者>として、<機能>が欲しい。そうすれば、<メリット>を得られる
1. モバイルバンキングの顧客として、口座残高を確認したい。そうすれば、支出についてより適切な判断ができる

このユーザーストーリーのリストは非常に詳細なものとし、機能のあらゆる側面を網羅します。

実装上の決定事項

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

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

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

テストに関する決定事項

決定したテストに関する事項のリスト。以下を含めます。

  • 良いテストの条件(実装の詳細ではなく、外部から見た動作のみをテストする)
  • テスト対象のモジュール
  • テストの先例(コードベース内にある、類似した種類のテストなど)

対象外

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

補足

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

コメント