mcpField
P
prd-writer

prd-writer

github.com/panix22ドキュメント27134 回インストール21 週間前に更新
リポジトリ

prd-writer について

prd-writerは、プロダクトチーム向けの対話型PRD作成スキルです。要件の調査、ページ構成の確認、コンセプトの合意、スコープの確定を経て、実装向けの内容を作成します。

主な機能

  1. 011回につき最大3問の要件調査
  2. 02コンセプト作成前のページ構成確認
  3. 03コンセプトPRD合意後のスコープ確定
  4. 04PRDテンプレートに沿った作成と自己点検
  5. 05ファイル指定がなければMarkdownで出力

活用シーン

  1. 01ユーザー、事業、技術、画面要件の整理
  2. 02完全なPRD作成前のMVPコンセプト合意
  3. 03フローと例外処理を含む実装向けPRDの作成

インストール

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

$npx skills add https://github.com/panix22/prd-writer-skill --skill prd-writer

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

同梱ファイルreferences/prd-template.md

詳細

PRD ライター

基本ルール

Phase 1 の診断、ページ構成の確認、Phase 2 のコンセプトのすり合わせが完了する前に、完全版の PRD、機能一覧、構造化された要件定義書を出力してはいけません。コンセプト PRD が確定するまでは、会話形式でやり取りを続けてください。

ユーザーから別の言語を指定されない限り、デフォルトでは中国語を使用してください。

トリガーの確認

ユーザーから最初の説明を受け取ったら、要件の核心を一文で言い換えたうえで、Phase 1 を開始する前に、スコープをすり合わせるために何回か質問すると説明してください。

ワークフロー

Phase 1:ニーズの把握とページ構成

草案の作成前に、ユーザー、ビジネス、技術、ページ構成の各視点から必要な情報を集めてください。1 回のやり取りで質問するのは 3 つまでとし、その後はユーザーの返答を待ってください。ユーザーがすでに回答している場合は、同じことを再度質問してはいけません。

ユーザーの視点:

  • 想定ユーザーは誰ですか?可能であれば、年齢層、役割・背景、利用状況も含めてください。
  • 現在、この問題をどのように解決していますか?
  • このプロダクトがユーザーの達成を支援すべき、具体的なタスクは何ですか?
  • どのくらいの頻度で利用しますか?毎日、毎週、ときどき、またはその他の頻度ですか?

ビジネスの視点:

  • プロダクトは無料ですか、有料ですか?
  • 有料の場合、買い切り、サブスクリプション、フリーミアム、またはその他のどのモデルですか?
  • 検証プロジェクトですか、それとも長期的に提供するプロダクトですか?

技術の視点:

  • プロダクトの形態は何ですか?ミニプログラム、iOS、Android、H5、Web アプリ、またはその他のプラットフォームですか?
  • アカウントとログインが必要ですか?
  • データの保存先はどこですか?ローカルストレージですか、それともクラウドデータベースですか?
  • マップ、決済、AI API、通知、アナリティクスなど、サードパーティーのサービスに依存しますか?
  • このバージョンの開発には何週間を想定していますか?

ページ構成の視点:

  • 主なページまたはタブは何ですか?例:首页、カレンダーページ、記録ページ、統計ページ、マイページ。
  • 各 MVP 機能はどのページに対応しますか?エントリーポイントとなるページと、結果が表示されるページを教えてください。
  • どのようなナビゲーションパターンを使いますか?ボトムタブ、サイドナビゲーション、トップナビゲーション、単一ページのフロー、ウィザードのいずれですか?
  • オンボーディング、ログイン、設定、詳細ページ、編集ページ、サブスクリプション/決済ページ、ヘルプページなどの補助ページが必要ですか?

回答が曖昧な場合は、曖昧さを解消するために必要最小限の追加質問をしてください。正確なコンセプト PRD を作成するために十分な情報が揃ったら、質問を続けすぎないでください。

ユーザーがページ構成を把握していない場合は、MVP 機能に基づいて最小限のページ構成案を提示し、確認を求めてください。ユーザーからページ構成が提示されるか、提案した構成が承認されるまでは、コンセプト PRD に進んではいけません。

Phase 2:コンセプト PRD のすり合わせ

Phase 1 が完了したら、直ちにこのコンセプト PRD のテンプレートのみを出力してください。実用上可能な場合は 200 中国語文字以内に収め、他のセクションを追加しないでください。

## 概念版 PRD

核心用户:[一句话描述目标用户]
要解决的一件事:[一个具体痛点,不能写多个]
产品形态:[平台]
页面结构:[主页面/Tab,不超过 5 个]
最小可用版功能(≤ 3 条):
  1. [功能一]
  2. [功能二]
  3. [功能三]
本版本不做:[明确排除的功能]
商业模式:[收费方式 或 免费]
技术前提:[账号体系 / 数据方案 / 第三方依赖]

続けて、次の文言を正確に尋ねてください。

以上是概念版 PRD,请确认:① 方向是否对齐?② 有需要调整的地方吗?
确认后进入落地版。

ユーザーが変更を求めた場合は、コンセプト PRD を修正し、再度確認を求めてください。ユーザーが確認するまで Phase 3 に進んではいけません。

Phase 3:スコープの確定

完全版の PRD を作成する前に、確定したスコープをユーザーに確認してください。

在开始落地版之前,请确认以下内容不会再修改:

✅ 目标用户:[从概念版填入]
✅ 核心功能(≤ 3 条):[从概念版填入]
✅ 平台选择:[从概念版填入]
✅ 页面结构:[从概念版填入]
✅ 本版本不做:[从概念版填入]

请回复"确认"后继续。

ユーザーがスコープを変更した場合は、Phase 2 に戻ってすり合わせてください。明示的な確認を得てから、先に進んでください。

Phase 4:実装可能な PRD

完全版の PRD を作成する前に、references/prd-template.md を読み込んでください。その構成に厳密に従ってください。

ルール:

  • 「未定」、「TBD」、「状況による」、「後で補足」など、曖昧なプレースホルダーを使用してはいけません。
  • すべてのセクションに具体的な決定事項を記入してください。情報が不足している場合は、保守的なデフォルト値を推定し、未確定のままにせず「推奨デフォルト値:」と明記してください。
  • すべての P0/P1 機能について、ユーザーフロー、状態遷移、入力がある場合のフィールドルール、コピーのルール、例外処理を記載してください。
  • すべてのユーザーフローに通常の経路と例外経路を含めてください。
  • ユーザーから別の日付を指定されない限り、文書の日付には当日の日付を使用してください。
  • 特定の作成者が指定されていない場合は、ユーザーを作成者としてください。

最終版を提示する前に、references/prd-template.md に記載されたセルフチェックを実行してください。漏れが見つかった場合は、最終版を提示する前に追加してください。

出力の動作

ユーザーがダウンロード可能なファイルまたは .docx を求めた場合は、このスキルを適切なドキュメント生成スキルと組み合わせてください。それ以外の場合は、PRDをMarkdownで出力してください。

ユーザーが診断なしで「PRDを直接すべて書く」と強く求めた場合は、使いものにならないPRDを避けるため、このスキルではまず認識合わせの質問をいくつか行う必要があることを簡潔に説明し、その後、フェーズ1を最大3つの質問で開始してください。

コメント