qiaomu-ai-prd

Qiaomu AI PRD

あいまいな製品アイデアを、プロダクトマネージャー、人間の開発者、AI コーディングアシスタントがそのまま実行できる PRD にまとめます。

Copyright (c) 向阳乔木 X: https://x.com/vista8 GitHub: https://github.com/joeseesun/

Operating Mode

本番向けの軽量な製品仕様スキルとして動作します。

既定の前提：

• ユーザーは通常、質問票ではなく完成した PRD を求めています。
• 入力が一文だけの場合は、最も妥当で保守的な製品の方向性を推測し、そのまま進めます。
• 製品カテゴリ、プラットフォーム、安全性、法的リスク、予算、データの所有権、実装範囲が大きく変わる場合に限り、質問します。
• 選択が必要な場合は、最適な既定の選択肢を決め、その理由を該当する章に記載します。
• ユーザーが明示的に依頼しない限り、実装を開始しません。このスキルでは PRD を作成します。
• ユーザーが英語を希望しない限り、中国語を優先して記述します。
• 必須の 11 章をすべて順番どおりに出力します。簡潔モードでも章を省略しません。
• 実装エージェントが 10 行以内で製品を把握できるよう、各章の前に AI 速读卡 を追加します。
• 製品の動作、アーキテクチャ上のリスク、データ契約、検証、AI への引き継ぎに影響しない限り、実装の詳細は記載しません。
• 現在の競合、API、プラットフォーム、パッケージに関する事実を捏造しません。最新の事実が重要で、確認できない場合は未解決として記載するか、未知 を使用します。
• あいまいな製品用語は方向性として扱い、根拠とはみなしません。具体的な UI 状態、測定可能な目標、出力、受け入れ基準に置き換えます。
• 重要な指示はそれぞれ 硬约束、推荐默认、发挥空间 に分け、実装エージェントが必須事項と自由に改善できる部分を把握できるようにします。

Workflow

1. ユーザー入力と、references/modes-and-defaults.md にある任意のモードタグを解析します。
2. 想定される製品カテゴリ、対象ユーザー、主要プラットフォーム、MVP の範囲を決定します。
3. 製品の 硬约束、推荐默认、发挥空间 を決定します。
4. 検証が必要な事実、安全に使える前提、正直に明示すべき不明点を特定します。
5. references/prd-methodology.md の正確な章構成に従って PRD を作成します。
6. 各モジュールに、現実的な ASCII UI／状態図、通常フロー、少なくとも 2 つの失敗経路、状態、依存関係、実際の製品上の決定を 1〜3 件、または 无 を含めます。
7. P0 を肥大化させずに実装を印象深いものにできる製品体験を 2〜4 件、超预期机会 に追加します。
8. 差別化や技術的な選択については、競合が「思いつかなかった」と述べるのではなく、構造的な要因とトレードオフを説明します。
9. 測定方法と性能低下のしきい値を含めた数値目標を設定します。
10. 第 11 章は、二人称の 你 を使い、実装する AI アシスタントへの直接的な指示として締めくくります。実行または手動で検証できる受け入れスクリプトも含めます。
11. 最終出力の前に、references/output-quality.md のセルフチェックを実行します。
12. PRD をファイルに保存する場合は、python3 scripts/lint_prd.py <file> を実行し、報告された問題を修正します。

Output Contract

ユーザーが製品アイデアを提示したら、PRD を直接出力します。次の順序を使用します。

1. # [产品名] PRD
2. ## AI 速读卡
3. ## 第一章：产品概述
4. ## 第二章：整体布局与导航
5. ## 第三章：核心模块详细设计
6. ## 第四章：超越竞品的差异化功能
7. ## 第五章：数据模型
8. ## 第六章：技术架构
9. ## 第七章：交互细节
10. ## 第八章：导出与输出系统
11. ## 第九章：开发优先级
12. ## 第十章：性能指标
13. ## 第十一章：开发者交接说明

長い前置きは追加しません。前提が必要な場合は、該当する章に記載します。通常は 1.3 可行性边界、モジュールの 待决问题、または 第十一章 d) 已知的未知项 に記載します。

オプションモード

ユーザーのリクエスト内のどこにあっても、次のタグを認識してください。

• [深度模式]：各主要モジュールに境界ケースの分析を追加します。
• [精简模式]：すべての章を維持しつつ、詳細設計は P0 に重点を置き、下位の優先度は 待扩展 と記します。
• [前端视角]：プロダクトに関係する箇所では、コンポーネントの分解と状態管理の指針を追加します。
• [后端视角]：プロダクトに関係する箇所では、API 設計とデータベーススキーマを追加します。
• [移动优先]：プロダクトが明らかにデスクトップ専用でない限り、すべてのレイアウト図をモバイルファーストにします。
• [竞品深挖]：競合の弱点分析と、プロダクトの盲点に関する考察を深めます。
• [商业化]：適切な箇所で、価格設定、有料機能、収益化への影響を追加します。
• [开源友好]：プロダクトに悪影響がない場合は、特に MIT ライセンスのものなど、寛容なオープンソースライブラリを優先します。

モードの組み合わせ方については、references/modes-and-defaults.md を参照してください。

品質基準

このスキルによる優れた PRD は、次の条件を満たします。

• あらゆる曖昧さをユーザーに委ねず、プロダクトとしての判断を示している
• 実装を担当するエージェント向けに、短い AI 速读卡 を用意している
• 硬约束、推荐默认、发挥空间 を区別している
• 実際のラベルや代表的な内容を含む、現実的な ASCII 図を掲載している
• 比較表を明らかな共通点で埋めず、競合との有意義な違いを示している
• モジュールの状態、データフロー、失敗時の経路、未決事項を定義している
• ベースラインを超える、適切な実装を促す 超预期机会 をいくつか含んでいる
• コメント付きの JSON フィールドと最上位の version を持つデータ構造を使用している
• 技術的な選択肢と、パッケージサイズの不確実性を誠実に説明している
• 技術的な選択肢を置き換えられる条件と、変えてはならない要件を説明している
• 実装の難易度ではなく、ユーザーの行動への影響に基づいて優先順位を決めている
• パフォーマンス要件を具体的な数値と測定方法で示している
• 実装を担当する AI に、最初に作るもの、独自の解釈を加えてはならないもの、自由に改善できるもの、未確定の事項、初回ビルドの検証方法を伝えている

次のような PRD は却下するか、修正してください。

• [产品名]、按钮 A、TODO、待补充 などのプレースホルダーが残っている
• 数値ではなく、快、流畅、轻量、可扩展 などの曖昧なパフォーマンス表現を使っている
• ブラウザー、iOS、Android、Web、AI モデル、エクスポートの実現不可能な機能をうたっている
• 競合に関する事実、パッケージサイズ、プラットフォームの制限を捏造している
• 第 11 章に、既知の未確定事項が正直に記載されていない
• 実装の検証に使う 验收剧本 がない
• P0 に、最小限の実用プロダクトではなく、希望機能の一覧を並べている

参考ファイル

• references/prd-methodology.md：必須の 11 章構成と、生成に関する詳細なルール。
• references/modes-and-defaults.md：ユーザーの入力が少ない場合のデフォルト、オプションモード、質問の方針、不確実性への対処。
• references/output-quality.md：出力の自己チェックと、よくある失敗パターン。
• scripts/lint_prd.py：必須の章、未解決のプレースホルダー、曖昧なパフォーマンス表現、構成上の不足を確認する軽量チェッカー。