write-user-story

ユーザーストーリーの作成

ソース資料をユーザーストーリー（または複数のストーリー）に変換します。各ストーリーの受け入れ基準は要件です。ストーリーが満たす必要のある、テスト可能で、独立したルールです。

データのソースが PR の場合は、qa-pr-requirements-analyzer スキルを使用してください。 ソースが課題管理システムのチケットの場合は、MCP 接続を依頼してください。

ルール

ユーザーストーリーは、少なくとも次の条件を満たす必要があります。

• 独立している — アクターは 1 つ、能力は 1 つです。
• 明確である — 曖昧な言葉（「速い」「関連性がある」「ユーザーフレンドリー」「期待どおりに動作する」「必要に応じて」）を使いません。
• 完全である — アクター、トリガー、結果、ビジネスルールを含み、受け入れ基準では空の状態、エラー、権限に関するパスも扱います。
• 一貫している — 用語を全体で統一し、矛盾がありません。
• テスト可能である — 各ストーリーに、合否を測定可能な受け入れ基準があります。

次のルールに従ってください。

• ユーザーストーリーを記述する際のその他のベストプラクティスに従ってください。
• 実装方法ではなく、何を実現するかを記述してください。ユーザーから求められていない限り、UI ウィジェット、API の実装詳細、フレームワークは含めません。
• 前提条件と未解決の質問を明示してください。不足しているルールを黙って作り出してはいけません。推測、想像、仮定はしないでください。不明な点があれば、必ずユーザーに確認してください。

出力

デフォルトでは、要件（説明）と受け入れ基準を出力します。ユーザーが形式を指定した場合は、その形式に合わせてください。（ユーザーから提供されたコンテキストに応じて、その他のセクションを追加します。）

各要件には、少なくとも 1 つの受け入れ基準が必要です。受け入れ基準には短く一意の ID（例：AC-1）を付けてください。（読みやすくするため、ID は行末に置くのがおすすめです。）

次のアクション

• 抜け漏れとテスト可能性を確認する → qa-requirement-reviewer
• リスクシナリオを検討する → qa-thinking
• これらのユーザーストーリーからテストケースを作成する → qa-write-test-cases