Acceptance Criteria Generation Prompt Template

This prompt is designed for teams that need to convert a requirement statement into a set of acceptance criteria that a tester, automation script, or downstream agent can execute without ambiguity. Use it when you have a functional requirement or user story and need criteria with clear preconditions, discrete test steps, and measurable expected outcomes. This prompt belongs in the planning pre-processing stage of an agent workflow, before task decomposition or execution begins. It assumes the input requirement is already clarified and scoped. If the requirement is still vague or contains unresolved constraints, run an Ambiguous Goal Refinement or Constraint Elicitation prompt first.

The ideal input is a single, self-contained requirement statement that describes a specific behavior or outcome. The prompt works best with requirements that have a clear actor, action, and expected result. It is not suitable for non-functional requirements like performance benchmarks or security policies unless those can be expressed as testable conditions. Do not use this prompt for exploratory testing scenarios where the expected outcome is unknown, or for requirements that span multiple independent workflows without clear boundaries. The output criteria are designed to be consumed by test automation frameworks, QA engineers, or verification agents that need step-by-step reproducibility.

Before invoking this prompt, confirm that the requirement has been reviewed for completeness and that any domain-specific terminology is defined. The prompt includes placeholders for [INPUT] (the requirement text), [CONTEXT] (system state, user role, or environmental conditions), and [CONSTRAINTS] (regulatory, technical, or business rules). If your workflow involves high-risk domains such as healthcare, finance, or safety-critical systems, pair this prompt with a human review step and an evidence-grounding check. The generated criteria should be treated as a draft that requires validation against the original requirement and any implicit assumptions the model may have introduced.

This prompt template is the core instruction set for generating structured acceptance criteria. It is designed to be pasted directly into the system or developer message of your model request. The prompt forces the model to produce a predictable JSON array, map each criterion back to the source requirement, and explicitly flag any criteria that cannot be tested. This structure is essential for downstream validation, automated test generation, and traceability audits.

textCopy
You are a requirements analyst converting a source requirement into a set of testable acceptance criteria.

Your task is to analyze the provided [REQUIREMENT] and produce a JSON array of acceptance criteria objects. Each object must include preconditions, test steps, and expected outcomes. You must also flag any criterion that is not practically testable and map every criterion back to the source requirement.

## Input
[REQUIREMENT]: The full text of the requirement to be decomposed.
[CONTEXT]: Optional additional context, such as product documentation, user stories, or technical constraints.
[CONSTRAINTS]: Optional constraints on the criteria, such as a maximum number of criteria, specific test environments, or regulatory standards to apply.

## Output Schema
Return ONLY a valid JSON object with the following structure. Do not include any text outside the JSON object.

{
  "requirement_id": "string",
  "criteria": [
    {
      "criterion_id": "AC-001",
      "description": "A concise description of the criterion.",
      "source_requirement_section": "Quote the specific part of the requirement this maps to.",
      "preconditions": [
        "State that must be true before the test can begin."
      ],
      "test_steps": [
        "Ordered action to perform."
      ],
      "expected_outcome": "The observable result that indicates success.",
      "is_testable": true,
      "untestable_reason": null
    }
  ]
}

## Instructions
1.  **Decompose the requirement** into discrete, independent acceptance criteria. Each criterion should verify one logical condition.
2.  **Write preconditions** that are specific and reproducible. Avoid vague states like "system is working."
3.  **Write test steps** as a clear, ordered sequence of actions. A new user should be able to follow them.
4.  **Define expected outcomes** that are observable and unambiguous. Use precise values where possible.
5.  **Map every criterion** back to the exact sentence or clause in the source requirement it validates. Use the `source_requirement_section` field.
6.  **Flag untestable criteria**: If a criterion cannot be verified through a practical test (e.g., it requires subjective judgment, access to unavailable systems, or infinite data), set `is_testable` to `false` and explain why in `untestable_reason`.
7.  **Ensure complete coverage**: After generating the list, review the source requirement and confirm that every functional and non-functional aspect is addressed by at least one criterion. If not, add the missing criteria.
8.  **Apply constraints**: If [CONSTRAINTS] are provided, ensure every criterion respects them. For example, if a regulatory standard is specified, include steps that verify compliance.

To adapt this template, replace the square-bracket placeholders with your actual data. The [REQUIREMENT] is the only strictly required input; the model can still produce useful output without [CONTEXT] or [CONSTRAINTS], but providing them will improve specificity and reduce the number of untestable criteria. For high-risk domains, ensure the [CONSTRAINTS] field includes any relevant regulatory or compliance standards. After pasting the prompt, always run the output through a JSON schema validator before ingesting it into your test management system. The next section covers how to wire this prompt into a production application harness with validation, retries, and logging.

This prompt is designed to be called programmatically from a product management tool, CI pipeline, or planning agent. The caller must supply a structured [REQUIREMENT] object containing the feature description, any existing constraints, and the target domain context. The model returns a JSON array of acceptance criteria objects, each with precondition, testSteps, and expectedOutcome fields. The application layer should validate this output before storing it or passing it to downstream systems such as test case generators or ticketing tools.

Validation and repair loop: Parse the model's JSON response immediately. Validate that every criterion object has all three required fields, that testSteps is a non-empty array, and that no criterion is a near-duplicate of another (use cosine similarity on concatenated field text with a threshold of 0.85). If validation fails, construct a repair prompt that includes the original requirement, the invalid output, and the specific validation errors, and retry once. If the retry also fails, log the failure and route to a human review queue rather than silently accepting incomplete criteria. Model choice: Use a model with strong JSON-following behavior and a context window large enough to hold the full requirement plus output schema. For high-stakes requirements (regulated domains, safety-critical features), add a [RISK_LEVEL] parameter that, when set to high, forces the prompt to include a mandatory human-approval step before criteria are considered final.

Integration points: Wire this prompt behind an API endpoint that accepts a requirement payload and returns validated criteria. In a CI pipeline, trigger the endpoint when a PRD or feature spec is merged, and post the generated criteria as a comment on the associated ticket. For agent workflows, treat the output as a planning artifact: the agent should not proceed to implementation until all criteria have a status: approved flag set by a human reviewer. Observability: Log the prompt version, model used, input requirement hash, validation pass/fail status, and any repair attempts. This trace data is essential for debugging criteria quality regressions when requirements change in structure or complexity. What to avoid: Do not bypass validation and feed raw model output directly into automated test generation. Do not use this prompt for requirements that are still in active debate; the input should be a stable, reviewed requirement, not a rough user story draft.