Retry and Recovery Scenario Generation Prompt

This prompt is designed for reliability engineers, QA leads, and platform engineers who need to translate defined failure modes and recovery mechanisms into automation-ready acceptance criteria. The core job-to-be-done is taking a known transient failure (like a network timeout, a 503 response, or a throttling event) and a documented recovery strategy (such as exponential backoff, a circuit breaker, or a fallback response) and producing a set of Gherkin scenarios that can be directly executed by a test framework. You should use this prompt when you have a concrete failure mode, a clear recovery mechanism, and a need for verifiable, behavior-driven specifications that can gate a release or validate an SLO.

The ideal input for this prompt is a structured description of the failure, the recovery policy parameters, and the system's expected behavior. For example, you might provide: 'The payment service returns a 503 error. The client retries up to 3 times with exponential backoff starting at 1 second. After 3 failures, the circuit breaker opens for 30 seconds and a cached fallback response is returned.' The prompt will then generate scenarios covering the happy retry path, the exhaustion of retries, the circuit breaker's half-open state, and the fallback response. It will also include boundary conditions like retry budget exhaustion exactly at the limit and recovery signal clarity after the breaker resets. The output is not just a list of scenarios; it includes tags for test automation, example data tables, and explicit assertions for timeout boundaries and state transitions.

Do not use this prompt for general error message testing, performance tuning, or user-facing copy review. Those workflows require different inputs and produce different outputs. This prompt is also not a substitute for a full chaos engineering plan; it focuses on the deterministic behavior of a single component's recovery logic, not on emergent system-wide failures. Before using this prompt, ensure you have a written retry policy, backoff configuration, or circuit breaker specification. If you are still exploring what the recovery behavior should be, start with the 'Error Handling Behavior Specification Prompt' or the 'Ambiguous Requirement Clarification Prompt' to define the policy first. Once the policy is stable, return here to generate the executable scenarios that will validate it in your CI/CD pipeline.

This prompt template is designed to produce executable Gherkin scenarios for transient failure and recovery paths. It forces the model to reason about retry policies, backoff strategies, circuit breaker states, fallback responses, and recovery signals. Use it when you have a defined system boundary, a known set of dependencies, and a clear recovery policy to validate. Do not use it for generic error handling or for systems where the failure modes are not yet understood.

textCopy
You are a reliability test engineer. Your task is to generate Gherkin scenarios that validate system behavior during transient failures and recovery.

## System Under Test
[SYSTEM_DESCRIPTION]

## Dependencies and Failure Points
[DEPENDENCY_LIST]

## Retry and Recovery Policies
[POLICY_DESCRIPTION]

## Constraints
- Generate scenarios only for transient and recoverable failures. Do not generate scenarios for permanent failures unless they trigger a defined fallback.
- Each scenario must include explicit timeout boundaries, retry counts, and backoff expectations.
- Use concrete, verifiable assertions for recovery signals (e.g., log entries, metrics, response fields).
- Tag each scenario with the failure mode it covers (e.g., @timeout, @circuit_open, @max_retry_exhausted).
- If a policy is undefined for a failure mode, generate a scenario tagged @policy_gap.

## Output Schema
Return a JSON object with a single key "scenarios" containing an array of objects. Each object must have:
- "name": A concise scenario title.
- "tags": An array of strings representing failure mode tags.
- "feature": The feature or component under test.
- "scenario": The Gherkin text block.
- "recovery_signal": A description of how to verify the system recovered correctly.

## Examples
[FEW_SHOT_EXAMPLES]

Generate scenarios for the system and policies described above.

To adapt this prompt, replace the square-bracket placeholders with your specific context. [SYSTEM_DESCRIPTION] should detail the component, its API, and its operational boundaries. [DEPENDENCY_LIST] must enumerate every external service, database, or queue the system relies on. [POLICY_DESCRIPTION] is the most critical input: specify exact retry counts, backoff algorithms (e.g., exponential with jitter), circuit breaker thresholds, and fallback responses. Provide [FEW_SHOT_EXAMPLES] that match your expected output format and domain language to improve reliability. After generation, validate that every scenario has a concrete, measurable recovery signal and that no undefined failure modes are left untagged.

This prompt is designed to be called programmatically from a test planning pipeline or a QA chatbot interface. The primary input is a structured specification of a system component, its failure modes, and its expected recovery behavior. The output is a set of Gherkin scenarios that must be validated before they are committed to a test repository. Because the generated scenarios directly influence reliability testing, the implementation harness must enforce schema validation, retry logic, and a human review step for any scenario that introduces a new retry policy or circuit breaker state.

To wire this into an application, wrap the prompt in a function that accepts a [COMPONENT_SPEC] object containing the service name, its dependencies, timeout configurations, and known failure modes. The function should call the LLM with the prompt template, then parse the response into a structured object matching the [OUTPUT_SCHEMA]—a list of Gherkin scenarios with tags for @retry, @circuit-breaker, @fallback, and @degradation. Implement a post-generation validator that checks each scenario for: (1) a valid Given-When-Then structure, (2) explicit timeout boundaries in the When step, (3) a clear recovery signal in the Then step, and (4) no unresolved placeholders. If validation fails, retry once with the error message appended to the prompt as additional [CONSTRAINTS]. Log every generation attempt, validation result, and retry decision to your observability stack for traceability.

For high-risk systems where recovery behavior affects data integrity or user safety, route all generated scenarios through a human review queue before they are accepted. The review interface should display the original component spec, the generated Gherkin, and the validator's pass/fail results. Reviewers should confirm that retry exhaustion scenarios do not lead to silent data loss and that fallback responses are explicitly defined. Once approved, the scenarios can be automatically pushed to a test management system via API. Avoid treating this prompt as a fire-and-forget generator; the harness must enforce that every recovery path is explicit, testable, and reviewed before it becomes part of the reliability test suite.