• swing-review

  examines the CURRENT state — "what's wrong NOW?"

• swing-mortem

  examines the FUTURE — "what will go wrong LATER?"
• Adversarial review finds existing flaws. Pre-mortem anticipates flaws that don't exist yet.

1. Never produce generic risks. Every failure scenario must name specific technologies, quantities, timelines, or conditions. "The database might not scale" is banned. "PostgreSQL connection pool exhaustion at >2,000 concurrent users due to long-running analytical queries holding connections for 30s+" is acceptable.
2. Exactly 5 scenarios across 5 categories. One Technical, one Organizational, one External, one Temporal, one Assumption. No category may be skipped, no category may have more than one scenario.
3. Leading indicators must be observable and measurable. "Watch out for problems" is banned. Every indicator must specify what to measure, what threshold signals danger, and where to observe it.
4. Circuit breakers must include a specific trigger condition. "If things go wrong" is banned. Every trigger must be a measurable condition with a concrete threshold.
5. The swing-mortem summary is MANDATORY. It is the BLUF of the analysis. It must appear at the end and synthesize the highest risk, its leading indicator, and its escape hatch in one paragraph.
6. Assume complete failure. Not partial, not "underperformance." The premise is total failure. This extreme framing is what forces creative risk identification — do not soften it.
7. Specificity over coverage. One deeply analyzed, plausible failure scenario per category is worth more than five shallow ones. Depth beats breadth.

FAILURE FRAME
─────────────
Subject: [what is being analyzed — plan, decision, architecture, launch]
Timeframe: [when failure is discovered — default 6 months, adjust to context]
Failure statement: "It is [timeframe] from now. [Subject] has failed completely.
Not partially underperformed — completely failed. The team is conducting a
post-mortem. What went wrong?"

• If code/architecture exists, read relevant files to ground scenarios in reality
• If a project plan exists, examine timelines and dependencies
• If prior decisions are documented, review the rationale and constraints

RISK MATRIX
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
| # | Category       | Scenario             | Likelihood | Impact       | Priority |
|---|----------------|----------------------|------------|--------------|----------|
| 1 | Technical      | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 2 | Organizational | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 3 | External       | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 4 | Temporal       | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |
| 5 | Assumption     | [title]              | H / M / L  | Cat/Sev/Mod  | [rank]   |

• High + Catastrophic = P1
• High + Severe OR Medium + Catastrophic = P2
• Medium + Severe OR High + Moderate = P3
• Everything else = P4

It is [timeframe] from now. [Subject] has failed completely. What went wrong?

1. [Indicator name] — Measure: [what], Threshold: [value], Where: [location], Lead time: [duration]
2. [Indicator name] — Measure: [what], Threshold: [value], Where: [location], Lead time: [duration]

• Trigger: [specific measurable condition]
• Fallback: [concrete alternative]
• Cost of delay: [what you lose by waiting]
• Decision owner: [role]

• Watch out for scaling issues
• Monitor team communication
• Keep an eye on the market

• If things go wrong, switch to plan B
• If communication breaks down, have more meetings

**Why this is bad:**
- Every scenario is generic — could apply to literally any project
- No specific technologies, numbers, or conditions named
- "It didn't scale" is not a scenario — it's a category label
- Leading indicators are unmeasurable platitudes ("watch out for", "keep an eye on")
- Circuit breakers have no trigger thresholds and no concrete fallbacks
- "Have more meetings" is not a circuit breaker — it's a coping mechanism
- No risk matrix, no priority ranking, no swing-mortem summary

It is 6 months from now. The microservices migration has failed completely. The team reverted to the monolith. What went wrong?

1. Consumer lag growth rate — Measure: max consumer lag across all partitions for order-processing group. Threshold: >10,000 messages or lag growing >500 msg/sec for 5 consecutive minutes. Where: Kafka monitoring dashboard (Burrow or equivalent). Lead time: 2-4 hours before DLQ overflow at projected rates.
2. DLQ fill rate — Measure: dead letter queue size as percentage of allocated storage. Threshold: >30% capacity outside of known incident windows. Where: Kafka topic metrics + PagerDuty alert. Lead time: 1-2 hours before overflow.

• Trigger: Consumer lag exceeds 1 hour AND DLQ reaches 50% capacity during any traffic event exceeding 5x baseline.
• Fallback: Activate synchronous HTTP fallback path for order processing (already exists in monolith, needs a feature flag to route traffic). Accept the latency penalty (800ms vs 200ms) to guarantee zero order loss.
• Cost of delay: Each hour of delay at Black Friday volumes risks ~$30K in dropped orders. The fallback path adds 600ms latency but loses zero orders.
• Decision owner: On-call SRE lead with VP Engineering escalation.

• Before committing to a project plan or timeline
• Before making an irreversible architecture decision
• Before adopting a new technology in production
• Before a major feature launch or product pivot
• Before entering a new market or customer segment
• When the team is highly confident and nobody is raising concerns
• When stakes are high and the cost of failure exceeds the cost of analysis
• When someone says "what's the worst that could happen?"

• For existing flaws in current code (use

  swing-review

  — it examines what's wrong NOW)
• For comparing technology options (use

  swing-research

  — it gathers facts, not failure scenarios)
• For generating creative alternatives (use

  swing-options

  — different cognitive mode)
• For routine code review (use

  engineering:code-review

  )
• When the decision is trivially reversible (low stakes don't justify the analysis)
• When the team needs encouragement, not caution (read the room)

• With swing-clarify: Run swing-clarify first on ambiguous requests before invoking this skill. Clarified scope produces better results.
• With swing-review: Complementary, not overlapping. Run

  swing-mortem

  first to anticipate future risks, then

  swing-review

  on the current implementation to find existing flaws. Together they cover temporal risk: future (swing-mortem) + present (adversarial).
• With swing-research: When a swing-mortem scenario depends on uncertain facts (e.g., "will Kafka handle this load?"), invoke

  swing-research

  to verify the factual basis before rating likelihood.
• With swing-options: After swing-mortem reveals high-priority risks, use

  swing-options

  to generate alternative approaches that avoid the top failure modes entirely.
• With deep-dive-analyzer: For complex systems, run

  deep-dive-analyzer

  first to understand the full architecture, then

  swing-mortem

  to identify where it could fail. Understanding precedes risk analysis.
• With skill-composer: Chain as

  deep-dive-analyzer

  →

  swing-mortem

  →

  swing-options

  for a full "understand → anticipate failure → generate alternatives" pipeline.
• With orchestrator strategy team: Pre-mortem output feeds directly into the strategy team's Devil's Advocate agent for additional stress-testing of the risk assessment itself.