Adversarial Checklist

Input: $ARGUMENTS

Purpose

Normal checklists say “check X” and move on. Adversarial checklists say “check X — and if X looks fine, here’s how it could STILL be wrong.” They embed assumption-testing directly into the checklist format.

What this produces: A before-you-do-X checklist where each item has a “but what if?” branch that catches the failures normal checklists miss.

This is a compound skill — it chains 4 skills in sequence.

Depth Scaling

Default: 2x. Parse depth from $ARGUMENTS if specified (e.g., “/ac 4x [input]”).

These are floors. Go deeper where insight is dense. Compress where it’s not.

The Chain

Step 1: /aex     -- What do people assume when doing this action?
Step 2: /fla      -- What goes wrong despite those assumptions?
Step 3: /ai      -- What if each assumption is wrong?
Step 4: /stg          -- Create the checklist with adversarial branches

Execution Procedure

Step 1: Extract Assumptions People Make

-> INVOKE: /aex $ARGUMENTS

When people are about to do [action], what do they assume?

• What do they take for granted?
• What do they skip checking because “it’s obvious”?
• What hidden beliefs drive their preparation?

Target: 10-20 assumptions, ordered by how dangerous they are when wrong.

Output: Numbered list of assumptions with danger rating.

Step 2: Anticipate Failures

-> INVOKE: /fla [action + assumptions from Step 1]

For each assumption, what goes wrong when it fails?

• What’s the failure mode?
• How common is this failure?
• How bad is the outcome?
• How detectable is it before damage?

Output: Failure modes linked to assumptions, ranked by (frequency x severity).

Step 3: Invert Critical Assumptions

-> INVOKE: /ai [top 10-15 assumptions by danger]

For each critical assumption, ask:

• What would you see if this assumption were WRONG?
• What’s the earliest indicator of wrongness?
• What’s the cheapest test to check?

Output: For each assumption, an observable check and a quick test.

Step 4: Generate the Adversarial Checklist

-> INVOKE: /stg [assumptions, failures, inversions from Steps 1-3]

Create the checklist in this format:

BEFORE YOU [ACTION]: ADVERSARIAL CHECKLIST
==========================================

[ ] 1. CHECK: [What to verify]
       LOOKS GOOD? It could still be wrong if: [inversion]
       QUICK TEST: [How to actually verify in 2 minutes]
       IF WRONG: [What to do instead]

[ ] 2. CHECK: [Next item]
       LOOKS GOOD? It could still be wrong if: [inversion]
       QUICK TEST: [How to verify]
       IF WRONG: [What to do]

...

STOP-AND-THINK ITEMS (most commonly skipped):
[ ] [Item that feels unnecessary but catches the biggest failures]
[ ] [Item people skip because they're in a hurry]

RED FLAGS (stop everything if you see these):
- [Observable sign that something is fundamentally wrong]
- [Another red flag]

-> COMPLETE

Output Standards

• Plain language, no jargon
• Each item is a concrete CHECK, not “consider” or “think about”
• Every CHECK has a QUICK TEST (under 2 minutes to perform)
• Every CHECK has an IF WRONG action
• Include STOP-AND-THINK items (the ones people skip)
• Include RED FLAGS (stop everything signals)
• Printable on one page when possible (two pages max)
• Validation status: “This checklist has not been validated by domain experts”

What Makes This Different from Normal Checklists

The adversarial branch catches failures that happen AFTER you check the item and it looks fine.

Example Usage

/ac starting a new software project
/ac signing a lease or contract
/ac making a major purchase over $1000
/ac launching a product
/ac hiring a new employee
/ac before any important presentation