User Story Narrative to Acceptance Criteria Prompt Template

This prompt is designed for product engineering teams that need to convert free-text user story narratives into structured, testable acceptance criteria. The primary job-to-be-done is transforming a human-readable story like 'As a user, I want to reset my password so I can regain access to my account' into a typed record containing Given-When-Then scenarios, edge cases, and non-functional requirements. The ideal user is a product manager, technical lead, or QA engineer who needs to move from a narrative requirement to a machine-readable specification that can feed into test management tools, ticketing systems, or automated test generation pipelines. The prompt assumes you already have a well-formed user story narrative as input—it does not help you write the story itself.

Use this prompt when you have a complete user story narrative and need to produce structured acceptance criteria that are individually testable and collectively exhaustive. The prompt is particularly valuable in workflows where downstream systems expect typed records with fields like scenarios, edge_cases, and non_functional_requirements. It works best when the input story follows a standard format (role, goal, benefit) and contains enough detail to derive meaningful test conditions. The prompt includes validation checks for testability—each scenario must have observable preconditions, actions, and outcomes—and for scenario completeness, flagging missing edge cases or ambiguous acceptance conditions. For high-risk domains such as healthcare, finance, or safety-critical systems, you must add a human review step before accepting the generated criteria as requirements.

Do not use this prompt when the input is a vague one-line feature request, a bug report, or a technical task description that lacks a user-facing narrative. It is not designed for converting Jira tickets, support issues, or architectural decisions into acceptance criteria. If your input is a bug report, use the Bug Report Narrative to Structured Issue Prompt Template instead. If you need to extract requirements from meeting transcripts, use the Meeting Transcript to Action Items JSON Prompt Template. Avoid using this prompt when the story contains conflicting or contradictory statements without first resolving them—the model will produce criteria that inherit those conflicts. For stories that span multiple user roles or subsystems, consider splitting them into separate prompts per role to keep the acceptance criteria focused and testable.

This prompt template converts a free-text user story narrative into a structured JSON payload of acceptance criteria. It is designed for product engineering teams who need to move from a natural-language description of a feature to a set of testable, well-formed scenarios that can be consumed by test management tools, ticketing systems, or automated test harnesses. The template enforces Given-When-Then structure, requires edge case identification, and separates functional from non-functional requirements. Use this template when the input is a coherent user story narrative and the desired output is a machine-readable set of criteria. Do not use it for bug reports, technical tasks, or architectural epics without adapting the output schema.

textCopy
You are a requirements engineer converting a narrative user story into structured acceptance criteria.

INPUT USER STORY:
[USER_STORY_NARRATIVE]

OUTPUT SCHEMA:
{
  "story_summary": "<one-sentence summary of the user story>",
  "actor": "<the primary user or persona>",
  "goal": "<what the actor wants to accomplish>",
  "acceptance_criteria": [
    {
      "id": "AC-001",
      "scenario": "<descriptive name of the scenario>",
      "given": "<precondition or initial state>",
      "when": "<trigger or action>",
      "then": "<expected outcome, observable and testable>",
      "priority": "must-have | should-have | nice-to-have"
    }
  ],
  "edge_cases": [
    {
      "id": "EC-001",
      "condition": "<description of the edge condition>",
      "expected_behavior": "<how the system should handle it>",
      "recovery_action": "<fallback or error handling, if applicable>"
    }
  ],
  "non_functional_requirements": [
    {
      "id": "NFR-001",
      "category": "performance | security | accessibility | usability | reliability",
      "requirement": "<measurable requirement>",
      "measurement": "<how to verify it>"
    }
  ],
  "assumptions": ["<assumption made during criteria generation>"],
  "ambiguities": ["<unresolved ambiguity in the source narrative that needs clarification>"]
}

CONSTRAINTS:
- Every acceptance criterion must be independently testable.
- Given-When-Then statements must use concrete, observable conditions, not vague adjectives.
- Edge cases must include conditions not explicitly mentioned in the narrative but reasonably expected in production.
- Non-functional requirements must be measurable. Do not invent requirements not implied by the story.
- If the narrative is too vague to produce testable criteria, list the ambiguities and produce partial criteria with explicit assumptions.
- Do not add features or behavior not present in the source narrative.
- Assign priorities based on the narrative's emphasis. Default to "must-have" if unclear.

EXAMPLES:
[FEW_SHOT_EXAMPLES]

RISK LEVEL: [RISK_LEVEL]

To adapt this template, replace the square-bracket placeholders with your specific inputs. [USER_STORY_NARRATIVE] should contain the full text of the user story as written by the product owner or stakeholder. [FEW_SHOT_EXAMPLES] should include one or two worked examples showing a narrative and its corresponding structured output, which dramatically improves output consistency. [RISK_LEVEL] should be set to low, medium, or high to adjust the model's conservatism—high-risk domains like healthcare or finance should trigger more conservative criteria generation and flag more ambiguities. After generating the output, validate the JSON structure programmatically before ingestion. For high-risk workflows, require a human reviewer to confirm that no criteria were hallucinated and that edge cases are realistic. Run an eval suite that checks: (1) every AC has all required fields populated, (2) Given-When-Then statements contain no placeholder text, (3) edge case count is non-zero for non-trivial stories, and (4) ambiguities are listed when the narrative is genuinely underspecified.

This prompt is designed to sit inside a product management or issue-tracking workflow where a human provides a narrative user story and the system must return structured, testable acceptance criteria. The implementation harness should treat the model call as a conversion step in a larger pipeline: receive unstructured text, call the LLM, validate the output against the expected schema, and either pass the result downstream or trigger a repair loop. Because the output directly shapes development and QA work, the harness must enforce schema compliance, testability checks, and human approval before the criteria land in a backlog or sprint board.

Wire the prompt into your application as a typed function with the following contract: accept a user_story_narrative string and an optional context object containing product domain, existing terminology, and non-functional requirement categories. Return a structured AcceptanceCriteriaPayload containing an array of Scenario objects, each with given, when, then fields, plus edge_cases and non_functional_requirements arrays. Before the model call, inject the [OUTPUT_SCHEMA] placeholder with a JSON Schema definition that enforces required fields, string types, and array constraints. After the model responds, run a two-stage validator: first, a structural validator that checks JSON parseability, field presence, and type correctness; second, a testability validator that scores each scenario for measurable conditions—reject or flag any then clause that uses vague language like "works correctly" or "is fast" without a quantifiable metric. If validation fails, route the output to a repair prompt from the Output Repair and Validation Prompts pillar rather than retrying the original prompt blindly.

For production deployment, use a model with strong structured output support (GPT-4o, Claude 3.5 Sonnet, or equivalent) and set response_format to json_object where the API supports it. Implement a retry budget of 2 attempts with exponential backoff; if both attempts fail validation, escalate to a human review queue with the original narrative, the failed output, and the specific validation errors surfaced. Log every conversion attempt with the prompt version, model, input hash, output, validation result, and human decision for auditability. Do not auto-commit acceptance criteria to a backlog without human approval—this workflow is high-stakes because incorrect or untestable criteria waste engineering cycles. The harness should also detect when the input narrative is too vague to produce testable criteria and return a clarification request to the user rather than hallucinating specifics.