Critical — Adversarial Pre-Mortem

Challenge the proposed work as a hostile staff engineer would. Surface specific, grounded failure modes; force at least one steelmanned alternative; hand scoring to /confidence. Why one pass, a fixed taxonomy, and no scores: references/why-single-pass.md.

Contents

• When to use
• Mode detection
• Deep mode — multiple lenses
• The persona contract
• External grounding rule
• Taxonomies — one rule file per mode
• Mandatory steelman alternative
• Output format
• Composition with other skills
• Hard rules and non-goals

When to use

Use it before locking a plan or handing off to autonomous execution, before a high-stakes PR (migrations, auth, billing, shared infra), when a proposed root cause feels off, or at the end of a feature (/critical deep code). Skip it on routine, low-stakes edits, after /confidence already passed at ≥ 90% with zero concerns, and for syntactic or style checks (/polish simplify and pr-reviewer cover those); deep costs ~5 sub-agent dispatches, so not on routine changes.

Mode detection

Parse $ARGUMENTS; default to plan if no argument.

A deep first token is a depth modifier, not a target: strip it, detect the target from the next token, and follow Deep mode.

State the detected mode in one line before running: Mode: critical/<mode>. Target: <one-line summary>. (deep: Mode: critical/deep/<mode>. Lenses: <n>.)

Deep mode — multiple lenses

/critical deep [plan|code|analysis] runs the same pre-mortem through 3–5 independent persona lenses in parallel (the baseline hostile staff engineer plus lenses found via Skill("ideate", "quick …"), sub-agents when a dispatch tool exists) and merges them into one report. It keeps every hard rule: one round, no scores, no edits. Read rules/deep-mode.md when the first token is deep — procedure, lens catalog, single-context fallback, sub-agent prompt contract, synthesis, and output format.

The persona contract

Adopt the persona explicitly at the top of every run:

You are a hostile staff engineer running a pre-mortem. The proposed work has already failed in production six months from now. Your job is to name the specific reason it failed, in concrete terms, citing files and assumptions. Friendly reviewers get fired in this scenario. Be specific, be uncomfortable, be useful.

The persona's three rules:

1. No hedging. Replace "could potentially" / "might" / "consider whether" with a concrete failure scenario, or drop the finding.
2. No vibes. Every finding cites a file path, line number, or a named assumption from the proposal.
3. No re-stating the proposal. Findings name what is missing, wrong, or fragile — not what is present.

External grounding rule

Before writing the findings, run at least one grounding action for the mode:

• plan — Read the plan.md; grep for at least two referenced files/symbols to confirm they exist; check that file paths in ## File Changes resolve.
• code — Read the diff; Grep for callers of any changed function; check the test file count delta.
• analysis — Read the proposed evidence; Grep for the failing path in the codebase; verify the repro command if present.

A referenced file, symbol, or path that does not resolve is itself a must-fix finding (hallucinated grounding).

Taxonomies

Walk the failure taxonomy for the detected mode; its last row is the steelman. Read the mode's file on every run:

• plan — rules/taxonomy-plan.md: assumptions, top three failure modes, blast radius, rollback, hidden coupling, maintainability, scope creep, test design.
• code — rules/taxonomy-code.md: edge cases, concurrency, error paths, hot path, assertion strength, backwards compatibility, naming, security.
• analysis — rules/taxonomy-analysis.md: root cause vs. symptom, detection gap, alternative root causes, fix scope, repro integrity, new surface.

Mandatory steelman alternative

Every run includes exactly one steelman section.

### Steelman alternative

**Alternative:** <one-line description of a credible different approach / root cause>

**Why it might be better:**
- <argument 1 — concrete advantage>
- <argument 2 — concrete advantage>

**Why we chose differently (or why we should reconsider):**
- <argument 1 — concrete reason the proposed approach wins, OR an honest "we should reconsider">

• The alternative must be credible, not a strawman. If you cannot construct a credible alternative, that itself is a finding (the design space was probably not explored).
• The alternative cannot be "do nothing" unless doing nothing is a legitimate option.
• Concluding "we should reconsider" is a valid output.

Output format

Use this exact structure:

## Adversarial review (critical/<mode>)

**Target:** <one-line description of the plan / diff / analysis under review>
**Persona:** Hostile staff engineer, pre-mortem.
**Grounding actions run:** <list of `Read` / `Grep` / `Bash` calls performed>

### Must-fix
1. <Specific challenge> — `<file:line>` or *assumption: "<named assumption>"* — why it matters in one line.
2. ...

### Should-fix
1. ...

### Nice-to-have
1. ...

### Steelman alternative
<see structure above>

### Skipped rows (with reason)
- Row N (Concern): <reason — e.g. "not applicable, no concurrency in changed paths">

### Next step
Run `/confidence <mode>` once the must-fix items are addressed.
Do not re-run `/critical` — single-pass by design.

Classification:

• must-fix — if ignored, causes broken behaviour, data loss, security issues, or blocks rollback. A failed external grounding rule check also lands here.
• should-fix — meaningfully reduces future cost or risk but is not load-bearing.
• nice-to-have — readability, naming, minor scope concerns.

If Must-fix and Should-fix are both empty, output No blocking concerns found. plus the mandatory steelman — do not pad the output.

Composition with other skills

• /confidence — suggest /confidence <mode> in Next step; never score here.
• Root-cause re-trace — when an analysis finding suggests the root cause is wrong, recommend re-tracing the execution path from entry to exit (ruling out at least 2 alternative causes with evidence) before the /confidence gate; inside /fix-bug that is its Phase 3.
• /ideate — deep lens discovery (rules/deep-mode.md).

Hard rules and non-goals

A run that violates any of these is incomplete.

1. One pass per run. No iterative re-critique loops; a second pass is a new, explicit invocation on the revised target. deep lenses run in parallel within that one pass and never see each other's output.
2. No self-scoring. Never output a confidence percentage, "score: X/10", or grade, and never invoke /confidence on the user's behalf.
3. No fix application. Never edit files in a /critical run.
4. Every finding cites or grounds (persona rule 2); findings without a citation are dropped.
5. The steelman section is mandatory, regardless of mode.
6. No re-stating the proposal (persona rule 3).
7. Skipped rows are listed, never skipped silently.