ユーザーストーリー作成
仕様をエンジニアが構築可能なストーリーに変える
PRDや機能説明があり、それをスプリント内で実装できるほど小さく、エンジニアが推測する必要がないほど明確で、QAがいつ完了したか分かるほどテスト可能なユーザーストーリーに分解する必要があります。
プロンプトテンプレート
あなたは経験豊富なプロダクトマネージャーとして、機能をユーザーストーリーに分解してエンジニアリングチームに引き継ぎます。
以下が分解する機能または仕様です：
<context>
$ARGUMENTS
</context>
> 上記が空白の場合は、ユーザーに次のように尋ねてください：「{{PRD、機能説明、デザインリンク、または大まかな要件をここに貼り付けてください}}」
これを以下の構造を使用してユーザーストーリーに分解してください：
**タイトル：** 短く説明的なストーリー名
**ストーリー：** [特定のユーザー役割]として、[アクション]をしたい、なぜなら[利益/成果]のためである。
**受け入れ基準：**
- [ ] [前提条件]の場合、[アクション]をすると、[期待される結果]になる
- [ ] エッジケース、エラー状態、境界条件を含めること
- [ ] ストーリーごとに4～6の基準 — 明確であるために十分であり、ミニ仕様書にならないように
**優先度：** P0（ローンチに必須）、P1（あるべき）、またはP2（あると良い／将来）
**メモ：** 依存関係、デザイン参照、技術的考慮事項、または未解決の質問
以下の原則を適用してください：
- 各ストーリーは1スプリントで完了可能であること。大きすぎる場合は分割すること。
- ストーリーは独立していること — ストーリーBがストーリーAのリリースを待たなければならないような連鎖を避けること。
- 受け入れ基準はテスト可能な動作として記述し、曖昧な説明にしないこと。「ユーザーは成功メッセージを表示する」は良いが、「ユーザーは良い体験をする」は悪い。
- ハッピーパス以外も含めること。APIが失敗したときは？ユーザーにデータがないときは？レート制限に達したときは？
- 技術コンポーネントではなく、ユーザーワークフローごとにストーリーをグループ化すること。
- デザインインプット、API変更、またはクロスチームの依存関係を必要とするストーリーにフラグを付けること。
ヒント
- craft-spec の出力をこのスキルに渡すことで、PRDからユーザーストーリーへのクリーンなパイプラインを実現できます。
- ストーリーが大きくなりすぎる場合は、仕様のスコープを先にフェーズ分割する必要がある可能性があります。
- 最良の受け入れ基準はテストスクリプトのように読めること — QAエンジニアが質問せずに各項目を検証できるべきです。
- 「ゼロ状態」のストーリーを忘れないでください — データがないときにユーザーは何を見るか？これはほぼ常に見落とされます。