Resilience Anti-Pattern Detection Prompt

This prompt is designed for architects, SREs, and platform engineers who need a fast, automated first pass at identifying common resilience weaknesses in a system design. The primary job-to-be-done is to scan a structured description of a system's components, their interactions, and their stated resilience mechanisms, then produce a prioritized list of detected anti-patterns. Use it during design review meetings to ensure no obvious failure modes are overlooked, as a pre-production readiness gate before a service launches, or as a diagnostic tool during incident postmortems to map a recent outage back to a known architectural flaw. The ideal user has a solid understanding of distributed systems but wants a systematic checklist applied to their design to catch blind spots before they manifest in production.

To use this prompt effectively, you must provide a structured description of the system under review. This includes a list of components (services, databases, message queues), their synchronous and asynchronous interactions, and any explicitly configured resilience patterns like retries, timeouts, circuit breakers, or bulkheads. The prompt is most effective when the input is detailed and specific; a vague, high-level diagram will yield generic results. The output is a prioritized list of detected anti-patterns, each with a severity rating (e.g., Critical, High, Medium), the affected components, and actionable remediation guidance. This output is designed to be a starting point for a deeper discussion, not a final verdict. You should wire this into a review pipeline where the results are automatically attached to a design document or an architecture decision record (ADR) for traceability.

This prompt is not a replacement for formal failure mode and effects analysis (FMEA), chaos engineering experiments, or a thorough review by a senior principal engineer. It operates on known patterns and cannot reason about novel, system-specific failure modes that fall outside its catalog. Do not use it as the sole safety check for life-critical, financial, or high-safety systems where a missed anti-pattern could have severe consequences. In those high-risk contexts, the prompt's output must be treated as one input among many, requiring mandatory human review and approval before any design is finalized. The next step after receiving the output is to validate each finding against the actual system context, filter out false positives, and then create actionable tickets for the remediation of confirmed high-severity issues.

This prompt template is designed to be copied directly into your AI orchestration layer, evaluation harness, or internal tooling. It accepts a system design description and a set of constraints, then produces a structured, prioritized list of detected resilience anti-patterns. Every placeholder is enclosed in square brackets and must be replaced with concrete values before execution. The template is self-contained and does not depend on external retrieval or tool calls unless you explicitly wire them in.

textCopy
You are a senior reliability architect reviewing a system design for resilience anti-patterns.

Your task is to analyze the provided system design and identify specific, named resilience anti-patterns that could lead to production failures.

## INPUT
System Design Description:
[SYSTEM_DESCRIPTION]

## CONSTRAINTS
- Focus on the following resilience dimensions: [RESILIENCE_DIMENSIONS]
- Known technology stack: [TECH_STACK]
- Deployment model: [DEPLOYMENT_MODEL]
- Risk tolerance level: [RISK_LEVEL]

## OUTPUT SCHEMA
Return a valid JSON object with the following structure:
{
  "analysis_summary": "A one-paragraph summary of the overall resilience posture.",
  "detected_anti_patterns": [
    {
      "anti_pattern_name": "Name from the resilience anti-pattern catalog.",
      "severity": "CRITICAL | HIGH | MEDIUM | LOW",
      "affected_components": ["component_name"],
      "description": "How this anti-pattern manifests in the provided design.",
      "failure_scenario": "A concrete scenario where this anti-pattern causes an incident.",
      "remediation_guidance": "Specific, actionable steps to fix or mitigate the anti-pattern.",
      "references": ["Optional link or standard reference."]
    }
  ],
  "false_positive_notes": ["Any patterns that might look like anti-patterns but are acceptable given the constraints."]
}

## INSTRUCTIONS
1. Scan the entire design for patterns from the standard resilience anti-pattern catalog, including but not limited to: Single Point of Failure, Retry Storm, Cascading Failure, Thundering Herd, Unbounded Queue, Missing Circuit Breaker, Tight Coupling, No Idempotency, Timeout Mismatch, Missing Health Checks, Shared Fate, and No Graceful Degradation.
2. For each detected anti-pattern, explain exactly where it appears in the design and why it is a risk.
3. Do not invent anti-patterns that are not present in the design.
4. If the design is incomplete, note what information is missing and how it affects your analysis.
5. Prioritize findings by severity: CRITICAL (will cause an outage under normal conditions), HIGH (will cause an outage under failure conditions), MEDIUM (degrades reliability), LOW (best-practice gap).

To adapt this template, replace each square-bracket placeholder with concrete values. For [SYSTEM_DESCRIPTION], provide a detailed architectural description including service boundaries, communication patterns, data flows, and infrastructure choices. For [RESILIENCE_DIMENSIONS], specify which aspects of resilience to focus on, such as network failures, database outages, downstream service degradation. The [RISK_LEVEL] field calibrates the analysis sensitivity; use high for critical production systems where false negatives are unacceptable, or low for early-stage designs where you want to avoid overwhelming the team with findings. After generating output, always validate the JSON structure against the schema and run the results through your evaluation harness to filter false positives before presenting findings to the engineering team.

This prompt is designed to be integrated into a structured review pipeline, not used as a one-off chat. The most effective implementation treats the prompt as a stateless function that accepts a system design document and a reference pattern catalog, then returns a structured anti-pattern report. The harness is responsible for providing the correct inputs, validating the output schema, filtering false positives, and routing high-severity findings for human review. Do not rely on the model's internal knowledge of resilience patterns alone—always supply a [PATTERN_CATALOG] with explicit definitions, severity criteria, and example signatures to ground the detection logic and reduce hallucinated findings.

Integration pattern: Wrap the prompt in a service or CI job that accepts a design document (markdown, JSON, or structured architecture description) and a catalog version. The harness should: (1) preprocess the design document to extract component boundaries, communication paths, and dependency graphs; (2) assemble the prompt with the extracted context, catalog, and output schema; (3) call the model with response_format set to the JSON schema defined in the prompt; (4) validate the returned JSON against the schema, rejecting malformed responses and retrying once with a repair prompt if validation fails; (5) run a false-positive filter that cross-references each detected anti-pattern against the catalog's required preconditions—if a finding claims a missing circuit breaker but the component is a batch processor with no external calls, suppress it; (6) route findings with severity: critical or severity: high to a human review queue with the source design excerpt and catalog reference attached. Log every step, including the raw prompt, model response, validation result, and suppression decisions, for auditability and prompt iteration.

Model choice and performance: Use a model with strong structured output support and a context window large enough to hold the design document plus the pattern catalog. GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro are suitable for production use. For design documents exceeding ~20K tokens, implement a chunking strategy: split the design by architectural layer or bounded context, run the prompt on each chunk independently, then merge findings and deduplicate by component name and anti-pattern type. Set temperature=0 for deterministic, repeatable results. If your pipeline runs on every design change, cache results keyed by a hash of the design document and catalog version to avoid redundant model calls. For high-throughput CI environments, batch reviews and enforce a timeout of 30–60 seconds per prompt call, with a fallback that flags the component as unreviewed rather than blocking the pipeline.

Evals and continuous improvement: Before deploying, build a golden test set of 10–15 design documents with known anti-patterns (both present and absent) and expected findings. Run the harness against this set and measure precision (what fraction of reported findings are real) and recall (what fraction of real anti-patterns were found). Set a release gate: precision must exceed 0.85 and recall must exceed 0.80 before the prompt enters production. After deployment, sample 5% of findings weekly for human review and track the false-positive rate over time. When the pattern catalog is updated, re-run the golden set and review any regressions. Store all eval results alongside the prompt version and catalog version so you can trace performance shifts to specific changes. Avoid the temptation to tune the prompt for a single design—optimize for consistent behavior across diverse architectures.