prd-planner

prd-plannerスキルの概要

prd-plannerができること

prd-planner は、1回の長いプロンプトで済ませるのではなく、ファイルベースで継続的に進めるワークフローによって PRD（プロダクト要求仕様書）を作成するための Requirements Planning スキルです。価値は単に「PRDを書いてくれる」ことではありません。調査内容、前提条件、作業の進捗、最終的な要求、技術面のフォローアップを安定した別ファイルに分けて保持できるため、途中でエージェントが文脈を見失いにくくなります。

prd-plannerが向いている人

prd-planner が最も合うのは、一発生成の PRD 下書きでは物足りないチームや個人開発者です。特に、要件の探索、エッジケース整理、PRD 作成、技術設計までを追跡可能な形でつなげたい場合に効果的です。複数回に分けて要件を磨き込む前提なら、通常の単発プロンプトより prd-planner のほうが安定して使えます。

解決するジョブ

多くのユーザーが prd-planner を使う理由は、反復に耐える構造化された PRD 作成フローが必要だからです。要件を明確にし、メモを残し、実用的な PRD を作り、そのまま技術設計へ引き継げます。リポジトリでも、コンテキストの切り替え、考えの取りこぼし、PRD 出力のばらつきを解消する手段として位置づけられています。

prd-plannerの違い

prd-planner の大きな特徴は、4ファイル構成です。すべてを1つの回答に詰め込むのではなく、plan、notes、PRD、technical design を通常は docs/ 配下に共通のスコープ接頭辞付きで分けて作成します。見直し、レビュー、拡張を前提とする Requirements Planning では、この構成が特に効きます。

prd-plannerを選ぶべきでないケース

単なる短い機能概要がほしいだけ、ラフなブレストをしたいだけ、あるいは純粋にソリューションアーキテクチャ文書だけが必要、という場合には prd-planner は向きません。スキル自体も、PRD を明示的に求めていないアーキテクチャ専用の依頼は architecting-solutions を使うべきだと案内しています。

prd-plannerスキルの使い方

prd-plannerのインストール前提

このリポジトリでは、スキル自体に汎用的なパッケージインストーラは用意されていません。付属の README.md では、Claude の skills ディレクトリにローカルでシンボリックリンクする形式のインストール例が示されています。

ln -s ~/Documents/code/GitHub/agent-playbook/skills/prd-planner/SKILL.md ~/.claude/skills/prd-planner.md

別の skill loader を使っている場合は、あなたのエージェント基盤が想定するディレクトリ構成や登録方法に合わせて、このパターンを読み替えてください。GitHub 上では、スキルは zhaono1/agent-playbook の skills/prd-planner にあります。

最初に読むべきファイル

prd-planner install と評価を手早く進めるなら、次の順で読むのがおすすめです。

1. skills/prd-planner/SKILL.md
2. skills/prd-planner/README.md
3. skills/prd-planner/references/edge-case-analysis.md

SKILL.md では、発火条件、ワークフローの意図、必要なツール、コアとなるファイル構成を確認できます。リファレンス側には、PRD の質を実際に引き上げるエッジケース確認の具体的な観点がまとまっています。

prd-plannerが起動する条件

このスキルは、ユーザーが明示的に PRD を依頼した場合、「product requirements document」と表現した場合、またはそれに相当する中国語表現を使った場合に発火するよう設計されています。つまり、これは汎用プランニングスキルではありません。プロンプトが「PRD を作って」ではなく「アーキテクチャを設計して」に寄っていると、意図しないフローに入ったり、結果が弱くなったりする可能性があります。

想定される4ファイル構成

通常の prd-planner usage フローでは、短い kebab-case のスコープ名を使って、docs/ 配下に次の4ファイルが作成されます。

docs/{scope}-prd-task-plan.md
docs/{scope}-prd-notes.md
docs/{scope}-prd.md
docs/{scope}-tech.md

これが prd-planner の基本的な運用モデルです。ファイル作成や永続的な成果物を望まないなら、prd-planner はおそらく最適解ではありません。

prd-plannerに渡すべき入力

prd-planner は、次の情報を渡すと最も力を発揮します。

• 機能またはプロダクトの目標
• 対象ユーザー
• ビジネス目的または成功指標
• 期限、プラットフォーム、コンプライアンス、既存スタックなどの制約
• 既知の非目標
• 関連するコード、ドキュメント、チケット、サンプルへのリンク

これらがなくても PRD の下書きは可能ですが、前提の置き方により強く依存することになります。

粗い依頼を強いプロンプトに変える

弱いプロンプト:

Create a PRD for notifications.

より強いプロンプト:

Create a PRD for in-app notifications for our B2B admin dashboard.
Users are account admins and support managers.
Goal: reduce missed follow-up tasks and improve response SLA compliance.
Constraints: web app first, existing React frontend and Node backend, no push notifications in v1.
Non-goals: email campaign tooling, mobile support.
Please use docs/notifications as the scope basis and call out edge cases, permissions, and rollout risks.

後者のように書くと、prd-planner は一般論ではなく、状況に即した具体的な PRD を作りやすくなります。

実務でのおすすめ prd-plannerワークフロー

実運用では、次の流れが使いやすいです。

1. PRD を明示的に依頼する
2. ビジネス背景、スコープ、制約を渡す
3. スキルにファイル一式を作らせる
4. 最終 PRD だけでなく、まず notes ファイルを確認する
5. 前提のズレを早い段階で修正する
6. エッジケース、受け入れ条件、技術的影響について2回目の見直しを依頼する
7. 生成された *-tech.md を実装計画への橋渡しとして使う

ここが単発プロンプトとの差です。ゼロからやり直すのではなく、notes を編集してから再度統合させる形で反復できます。

エッジケースのリファレンスは早めに使う

最も有用な補助ファイルは references/edge-case-analysis.md です。要件タイプの分類や、削除戦略、ローディング状態、ページネーション、バリデーション、エラーハンドリングなどを調べるためのコードベース走査コマンドが含まれています。Requirements Planning では、弱い PRD がちょうどこうした抜け漏れで破綻しがちなため、この資料の価値は高いです。

出力品質を上げるリポジトリ固有のコツ

このスキルでは Read, Write, Edit, Bash, Grep, Glob, AskUserQuestion, WebSearch といったツールの利用が許可されています。実際のところ、prd-planner は何もないところから文章生成するためのものではなく、実コードベースを確認し、必要に応じて確認質問を返す前提で設計されています。ファイル書き込みやシェル検索が制限される環境では、本来の価値のかなりの部分が失われます。

既存プロダクト向けの最適な prd-plannerプロンプト

対象機能が既存システムに属しているなら、依頼文にコードベースの手がかりを直接入れるのが効果的です。たとえば次のようにします。

Create a PRD for bulk user deactivation.
Relevant areas:
- `src/features/users/`
- existing soft delete behavior
- admin audit log requirements
Please inspect current list, detail, and permission patterns before drafting requirements.

こうすると prd-planner は抽象的なプロダクト文章ではなく、現実の実装制約に根ざした要求整理に寄りやすくなります。

出力を採用する前に確認したいこと

PRD を最終版として扱う前に、prd-planner が次を押さえているか確認してください。

• ユーザーロールと権限
• 明示的な非目標
• エッジケースと失敗時の状態
• ロールアウトや移行に関する懸念
• 測定可能な成功基準
• 現行システムの挙動への依存関係

見た目が整った PRD でも、これらが抜けているなら依然として危険です。

prd-plannerスキル FAQ

prd-plannerは初心者にも向いているか

はい。作りたい機能の方向性はわかっているが、進め方の型がほしい初心者には向いています。ファイル構成があることで、何もない状態から書き始める負担はかなり減ります。ただし、プロダクト思考そのものを省略できるわけではありません。入力が弱ければ、要件も浅くなります。

prd-plannerは普通のPRDプロンプトと何が違うか

通常のプロンプトは、たいてい1つの文書を返して終わりです。prd-planner skill は、調査、進捗、成果物、技術面のフォローアップを分離した永続的な成果物を前提に設計されています。そのため、改訂の質が上がりやすく、途中で文脈を失いにくいのが違いです。

prd-plannerは新規プロダクト専用か

いいえ。むしろ既存プロダクトでより有効な場面があります。リファレンス資料が現行コードベースのパターン確認を促すため、実際の実装制約に沿った PRD を作りやすくなります。

prd-plannerをアーキテクチャ設計専用に使えるか

あまり適していません。スキル内でも、アーキテクチャのみを求める依頼は、実際に PRD を要求しているのでない限り architecting-solutions を使うべきと明記されています。prd-planner for Requirements Planning として使い、何でも受ける設計ツール扱いはしないほうがよいです。

prd-plannerにはファイル書き込み権限が必要か

意図されたワークフローを使いたいなら、実質的には必要です。prd-planner の価値の中心は、ファイルに書き出して反復できる点にあります。チャットだけの環境でもプロンプトの考え方自体は流用できますが、永続化モデルの恩恵は失われます。

どんなときにprd-plannerをスキップすべきか

1段落で済む短い要約、ユーザーストーリーだけ、あるいはまだスコープが固まっていない探索的なアイデア出しが目的なら、使わないほうがよいです。4ファイル運用の手間は、PRD をレビュー、改訂、エンジニアに引き渡す前提があるときにこそ見合います。

prd-plannerスキルを改善する方法

prd-plannerにより良いスコープ定義を渡す

品質を最も左右するのは、スコープの明確さです。短くて一意なスコープ名を付け、v1 に含めるものとスコープ外をはっきり定義してください。これでファイル名が整理され、要件の膨張も抑えやすくなります。

機能名だけでなくビジネス意図を渡す

「Build approvals」だけでは曖昧です。一方で「Build an approval flow for purchase requests over $5,000 to reduce manual finance review time by 40%」のように書けば、prd-planner はより良い目標、ユーザーストーリー、受け入れ条件に落とし込みやすくなります。

既知の制約は最初に渡す

利用スタック、コンプライアンス、スケジュール、組織上の境界、既存ワークフローは、早い段階で共有してください。多くのユーザーが思う以上に、これらの制約は PRD の形を左右します。制約が抜けると、魅力的でも使えない要求ができがちです。

前提条件の記録を明示的に求める

強い prd-planner guide パターンの1つは、エージェントに対して「前提は notes ファイルに分けて列挙し、確認が必要なものには印を付けて」と指示することです。これにより、未確認の推測が確定事項のように最終 PRD に紛れ込むのを防げます。

コードベースを踏まえたエッジケース分析を使う

ソースにアクセスできるなら、要件を固める前に、バリデーション、ページネーション、ローディング、権限、削除挙動の既存パターンを prd-planner に調べさせてください。ここでは付属のリファレンスファイルが特に有効で、「エッジケースを考慮して」という曖昧な助言を、実際に走査できる具体作業へ変えてくれます。

最終PRDの前にnotesファイルを確認する

*-prd.md しか読まないユーザーは多いですが、品質のボトルネックはたいてい *-prd-notes.md にあります。notes の時点で誤った前提を直すほうが、きれいに整ったが方向違いの PRD を後から書き直すより、はるかに低コストです。

文言だけでなく未決定事項を反復する

初回出力のあと、「もっと詳しく」だけで済ませないことが重要です。たとえば次のように、改善ポイントを具体的に指定してください。

• 成功指標をより明確にする
• 権限ルールを明示する
• 失敗時と復旧時のケースを追加する
• 依存関係を整理する
• ロールアウト順序を明確にする
• ステークホルダーに確認すべき未解決点を挙げる

こうした反復は、文書の長さではなく意思決定の質を高めます。

prd-plannerで起こりがちな失敗パターン

典型的な弱い出力には、次のような傾向があります。

• 実ユーザー文脈のない一般的なペルソナ
• 現行システムの挙動を無視した要件
• 非目標の欠落
• エッジケースの扱い不足
• テンプレート的な技術設計
• テスト可能性の低い曖昧な受け入れ条件

多くの場合、これはモデルの問題だけでなく入力の問題でもあります。

ステークホルダーレビューのループと組み合わせる

prd-planner usage は、初回出力を完成版ではなく作業ドラフトとして扱うと効果が上がります。プロダクト担当は PRD、エンジニアリングは技術設計、全員で前提条件を確認する、といった分担にするとよいでしょう。ファイルベースの構造は、この役割分担と相性が良いです。

自社テンプレートを標準化して定着させる

チームがこのワークフローを気に入ったなら、prd-planner の上に、自社向けのスコープ命名規則、docs/ の運用ルール、PRD セクション構成、レビュー用チェックリストを定義すると定着しやすくなります。スキル自体が土台として十分しっかりしているので、社内標準を重ねることで、実際に出荷につながる品質へ安定させやすくなります。