write-a-prd

name	write-a-prd
description	ユーザーインタビュー、コードベースの調査、モジュール設計を通じてPRDを作成します。ユーザーがPRDを書きたい、プロダクト要件定義書を作成したい、または新機能を計画したい場合に使用します。
ref	https://github.com/mattpocock/skills/blob/main/write-a-prd/SKILL.md

このスキルは、ユーザーがPRDを作成したいときに呼び出されます。必要ないと判断したステップはスキップして構いません。

1. ユーザーに、解決したい問題の詳細な説明と、解決策のアイデアがあればそれについて詳しく聞いてください。

2. リポジトリを調査して、ユーザーの主張を検証し、コードベースの現状を把握してください。

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

4. 実装を完了するために構築または修正が必要な主要モジュールの概要を作成してください。単独でテスト可能なDeep Moduleを抽出する機会を積極的に探してください。

Deep Module（Shallow Moduleとは対照的に）とは、めったに変更されないシンプルでテスト可能なインターフェースに多くの機能をカプセル化したものです。

これらのモジュールがユーザーの期待に合っているか確認してください。どのモジュールにテストを書くべきかユーザーに確認してください。

5. 問題と解決策の完全な理解が得られたら、以下のテンプレートを使用してPRDを作成してください。

問題の定義

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

解決策

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

ユーザーストーリー

ユーザーストーリーの長い番号付きリスト。各ユーザーストーリーは以下の形式で記述してください：

1. <アクター>として、<機能>がほしい。なぜなら<利点>だからだ。

1. モバイルバンキングの顧客として、口座の残高を確認したい。なぜなら支出についてより適切な判断ができるからだ。

このユーザーストーリーのリストは非常に網羅的であり、機能のあらゆる側面をカバーする必要があります。

実装に関する決定事項

行われた実装に関する決定事項のリスト。以下を含めることができます：

• 構築/修正するモジュール
• 修正するモジュールのインターフェース
• 開発者からの技術的な補足説明
• アーキテクチャに関する決定
• スキーマの変更
• APIコントラクト
• 特定のインタラクション

テストに関する決定事項

行われたテストに関する決定事項のリスト。以下を含めてください：

• 良いテストとは何かの説明（実装の詳細ではなく、外部の振る舞いのみをテストする）
• テスト対象のモジュール
• テストの先行事例（つまり、コードベース内の類似タイプのテスト）

スコープ外

このPRDのスコープ外となる事項の説明。

補足事項

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