product-spec-kit

概要

このスキルは、プロダクトマネージャーがプロダクト開発向けの、構造化された高品質なドキュメントを作成するのに役立ちます。包括的なドキュメント作成ワークフロー（PRD → Plan → Stories）と、単独の簡易課題（個々のストーリー、タスク、バグ）の両方に対応しています。

見出しやテンプレートのデフォルトコンテンツを含め、最終ファイルは必ずユーザーとのやり取りで使われている言語で作成してください。ユーザーが別の言語を明示的に指定した場合は、その言語を使用してください。

どのようなときに使いますか？

次のことをユーザーから依頼された場合に、このスキルを使用します。

• PRD 仕様を作成する
• エピックとストーリー／タスクを作成する
• Product Requirements Document（PRD）、リリース計画、ユーザーストーリーなどのプロダクト仕様を作成または明確化する
• 単独の PRD、計画、ストーリー、タスク、バグを作成する

コア原則憲章

すべてのドキュメントは、rules/product-speckit-constitution.md で定義されている憲章に従う必要があります。この憲章は、このスキルで作成されるすべてのプロダクトドキュメントを規定する、交渉の余地のない原則を定めたものです。これらの原則は、言語、ワークフローの種類（完全版または簡易版）、ドキュメント形式にかかわらず適用されます。

原則 I：完全かつ曖昧さのない要件

すべての要件は、予備知識のない読者にも、必要なこととその理由が理解できるほど明確でなければなりません。

原則 II：デザインに基づく受け入れ条件

受け入れ条件は、ビジュアルデザイン、ユーザーフロー、具体的な UI 要素に基づいて作成してください。推測に基づいて記述してはいけません。

原則 III：説明よりも機能を重視する

条件には、システムの見た目ではなく、システムが行うことを記述してください。動作、アクション、結果に焦点を当てます。

原則 IV：適切な詳細度

• PRD：大枠の要件と一般的なルール
• ストーリー：詳細で機能的な受け入れ条件
• 各ドキュメントは、互いに重複せず、それぞれの目的を果たすこと

原則 V：推測せず、必ず確認する

情報が不足している、または曖昧な場合：

• 具体的な質問をする
• デザインやモックアップを依頼する
• 以前の議論を参照する
• 不確かな項目に検証が必要であることを明記する
• 最終決定の前に確認を待つ

ワークフローまたはコマンド

• やり取りの開始 — 新しい仕様を始める方法: ユーザーが作成したい仕様の種類を提示していない場合は、必ず workflows/prod-start.md の指示に従って確認してください。ユーザーが作成したい仕様の種類を提示している場合は、開始ステップを省略してください。
• PRD の作成: ユーザーが PRD の作成を希望する場合は、workflows/prod-spec-prd.md の指示に従ってください。
• 仕様の明確化: ユーザーが仕様（PRD、計画、ストーリー、タスク、バグなど）の明確化を希望する場合は、workflows/prod-clarify.md の指示に従ってください。既存の仕様が提示されていない場合は、仕様の提示を依頼してください。
• 仕様の分割: ユーザーが PRD をエピック → ストーリー／タスクなどの小さな単位に分割したい場合は、workflows/prod-spec-breakdown.md の指示に従ってください。分割する前に、既存の PRD を検証するか、PRD を作成する必要があります。既存の PRD が提示されていない場合は、その提示を依頼してください。
• ストーリーの作成: ユーザーがストーリーの作成を希望する場合は、workflows/prod-spec-story.md の指示に従ってください。
• タスクの作成: ユーザーがタスクの作成を希望する場合は、workflows/prod-spec-task.md の指示に従ってください。