deliver-acceptance-criteria

受け入れ基準

受け入れ基準は、ストーリーや機能が完了したと判断するために満たすべき、観察可能な動作を定義します。このスキルでは、機能のコンテキストを、エンジニアや QA が意図を推測せずに検証できる、簡潔でテスト可能な Given／When／Then シナリオに変換します。

使用するタイミング

• ユーザーストーリー、PRD のセクション、または機能のスライスを定義した後
• 実装の明確な合格／不合格条件が必要なとき
• スプリント計画や引き継ぎに向けて、QA ですぐに使える基準を作成するとき
• ストーリーに、明示すべきエッジケース、エラーパス、または非機能要件があるとき

使用しないタイミング

• ユーザーストーリー自体が必要な場合 → deliver-user-stories を使用してください。このスキルは、すでに存在するストーリーを掘り下げます
• 機能全体にわたる体系的な失敗ケースの網羅が必要な場合 → deliver-edge-cases を使用してください。このスキルの対象は個々のストーリーです
• 基準を結び付けるストーリーやスライスがまだない場合 → 先に deliver-prd または deliver-user-stories を使用してください
• ストーリーの完了条件ではなく、実験の成功指標を定義する場合 → measure-experiment-design を使用してください
• 「回答の 90% が情報源に忠実である」のように、基準がモデル出力の割合である場合 → deliver-prd の AI Behavior and Evaluation セクションを使用してください。そこでは、割合を検証するには設計されたサンプルが必要であることと、サンプルが用意されるまで記録すべき内容が説明されています

手順

受け入れ基準の作成を依頼された場合は、次の手順に従ってください。

1. ストーリーまたは機能の範囲を確認する 対象となる作業の範囲を正確に特定します。範囲が不明確な場合は、基準を作成する前にユーザーストーリー、PRD のセクション、または機能の説明を求めてください。

2. 基本フローと例外を分ける まず主要な成功フローを示し、その後、見落とした場合に起こりやすい、またはコストが大きいエッジケースやエラー状態を追加します。

3. 各基準を観察可能なシナリオとして記述する Given／When／Then の形式のみを使用します。各基準は個別にテスト可能にし、実装の詳細は避けてください。

4. 復旧と失敗時の動作を網羅する 検証に失敗した場合、依存先を利用できない場合、または保存を完了できない場合に、ユーザーに何が表示され、何ができるかを記述します。

5. 非機能要件を含める ストーリーに関係する場合は、パフォーマンス、アクセシビリティ、セキュリティ、信頼性、または監査可能性に関する基準を追加します。

6. 重複や重なりを避ける 各基準では、1 つの結果をテストする必要があります。2 つの基準が同じ動作を表している場合は、意図が明確になるまで統合または分割してください。

7. テスト可能性を確認する 解釈に頼らず、レビュー担当者が各基準の合否を判断できるようにします。主観的な記述は、測定可能な結果を示す形に書き直してください。

出力仕様

出力形式には references/TEMPLATE.md を使用してください。完全な回答では、次の内容を満たす必要があります。

• 機能またはストーリーのコンテキストを再提示する
• 基準を基本フロー、エッジケース、エラー状態、非機能要件に分ける
• 各基準に明示的な Given／When／Then の記述を使用する
• コンテキストが不完全な場合は、前提または未解決の質問を記載する

品質チェックリスト

最終確認の前に、次の項目を確認してください。

• 基準が特定のストーリーまたは機能のスライスに対応している
• 最初に基本フローが網羅されている
• エッジケースが暗黙ではなく明示されている
• エラー状態に、ユーザーから見える復旧方法が含まれている
• 関連する場合、非機能要件が含まれている
• 各基準がテスト可能で、明確な結果を 1 つだけ持つ
• 受け入れ基準に実装の詳細が入り込んでいない

例

現実的な e コマースのチェックアウトフローに基づく完成例については、references/EXAMPLE.md を参照してください。