Circuit Breaker Design Review Prompt Template

This prompt is for SREs and backend engineers who need a structured, pre-production review of a circuit breaker configuration. The job-to-be-done is to take a raw specification—including failure thresholds, timeout windows, state transition logic, and fallback actions—and produce a systematic assessment that identifies misconfigured thresholds, missing failure modes, unsafe recovery paths, and gaps in fallback coverage. The ideal user is someone conducting a design review, a pull request review, or a pre-release resilience audit who needs to move beyond intuition and check a configuration against known failure patterns before it reaches production.

Use this prompt when you have a concrete circuit breaker specification to evaluate. The input should include explicit values for error threshold, timeout duration, half-open state behavior, and the fallback mechanism. The prompt is designed to reason about state machine transitions, resource exhaustion risks, and downstream impact. It is not a general resilience advisor. Do not use this prompt for runtime incident diagnosis, where you are reverse-engineering behavior from production logs, or for reviewing retry policies, bulkheads, or rate limiters in isolation—those require separate, focused prompts with different evaluation criteria. Using this prompt for a component that is not a circuit breaker will produce a misleading assessment.

Before running this prompt, gather the circuit breaker specification, the service's error budget or SLO context, and any known upstream or downstream dependencies. The prompt works best when the reviewer can provide concrete numbers, not vague descriptions. After receiving the assessment, treat high-severity findings—such as a missing fallback for an open circuit or a recovery path that can cause a thundering herd—as blocking issues that require a configuration change before deployment. The next step is to apply the recommended changes and re-run the review, not to deploy with acknowledged risks.

The prompt below is the core instruction set for the Circuit Breaker Design Review. It is designed to be copied directly into your AI harness, notebook, or evaluation runner. The model is instructed to act as a principal reliability architect and to produce a strictly structured JSON output. Every section of the output is tied to a specific resilience concern, making the review auditable and actionable.

textCopy
You are a principal reliability architect reviewing a circuit breaker design for a distributed system. Your task is to produce a structured JSON assessment of the provided circuit breaker specification. You must evaluate the design against standard resilience patterns, identify failure modes, and recommend concrete improvements.

## INPUT
[SPECIFICATION]

## CONSTRAINTS
- Base your analysis strictly on the provided specification and standard distributed systems resilience patterns.
- Do not invent details not present in the specification. If information is missing, flag it as a gap.
- Your output must be a single, valid JSON object conforming to the output schema.
- For any high-severity finding, you must propose a concrete mitigation.

## OUTPUT_SCHEMA
{
  "summary": "string (A one-paragraph executive summary of the design's overall resilience posture.)",
  "state_machine_analysis": {
    "closed_state": "string (Assessment of failure threshold configuration and error counting logic.)",
    "open_state": "string (Assessment of the timeout window and behavior when the circuit is open.)",
    "half_open_state": "string (Assessment of the probing strategy, request allowance, and transition logic back to closed or open.)"
  },
  "failure_mode_assessment": [
    {
      "failure_mode": "string (Description of a potential failure scenario.)",
      "severity": "string (One of: LOW, MEDIUM, HIGH, CRITICAL)",
      "likelihood": "string (One of: RARE, UNLIKELY, POSSIBLE, LIKELY)",
      "current_mitigation": "string (How the current design attempts to handle this, or 'None' if missing.)",
      "recommendation": "string (A concrete action to eliminate or reduce the risk.)"
    }
  ],
  "fallback_action_review": {
    "current_fallback": "string (Description of the defined fallback behavior when the circuit is open.)",
    "risks": ["string (List of risks associated with this fallback, e.g., stale data, degraded UX, cascading load.)"],
    "alternatives": ["string (List of alternative fallback strategies to consider.)"]
  },
  "configuration_recommendations": [
    {
      "parameter": "string (The configuration parameter, e.g., failure_threshold, timeout_window, half_open_max_requests.)",
      "current_value": "string (The value in the provided specification, or 'Not Specified'.)",
      "recommended_value": "string (A specific, justified recommendation.)",
      "rationale": "string (Why this change improves resilience.)"
    }
  ],
  "missing_information": ["string (List of critical details missing from the specification that prevent a complete review.)"],
  "overall_risk_score": "string (One of: LOW, MEDIUM, HIGH, CRITICAL)"
}

To adapt this template, replace the [SPECIFICATION] placeholder with your raw design notes, configuration files, or architecture decision record text. The prompt is self-contained and does not require external tools or retrieval, making it suitable for direct use in a chat interface or as a single-turn task in an automated pipeline. For high-risk production systems, always route the final JSON output to a human reviewer for approval before implementing any recommended configuration changes.

The Circuit Breaker Design Review prompt is designed to be integrated into a pre-production design review pipeline, not as a one-off chat interaction. The prompt expects a structured [DESIGN_SPEC] input containing the circuit breaker configuration, the service it protects, its dependencies, and the expected failure modes. Before calling the model, the application harness should validate that the input spec includes required fields: failure threshold, timeout window, half-open behavior, and fallback action. If any field is missing, the harness should return a validation error to the user rather than sending an incomplete spec to the model, which would produce an unreliable review.

For production integration, wrap the prompt in a function that accepts a validated design spec object and returns a structured assessment. Use a model with strong JSON mode or structured output support (e.g., GPT-4o with response_format or Claude with tool use) and enforce the [OUTPUT_SCHEMA] defined in the prompt template. The output should include a severity field (PASS, WARN, FAIL), a list of findings with category and recommendation, and a recovery_path_review object. Implement a post-processing validator that checks the output schema before surfacing results to the user. If the model returns a finding without a corresponding recommendation, or if the severity is FAIL but the findings list is empty, flag the response for human review rather than displaying it as a completed assessment.

Circuit breaker misconfiguration can cause cascading production failures, so this workflow should include a human approval gate for any FAIL severity result. Log every review to an audit table with the design spec hash, model version, timestamp, and reviewer identity. For teams running multiple reviews, cache common failure patterns in a vector store and use retrieval-augmented generation (RAG) to inject relevant past incidents into the [CONTEXT] field before each review. This prevents the model from missing failure modes that have already caused outages in your specific environment. Avoid running this prompt against live production configurations without a staging review step—the prompt assesses design intent, not runtime state, and conflating the two produces false confidence.