Challenge Plan

/challenge-plan - Challenge Plan

Overview

Stress-test a proposed plan before implementation begins. Extract assumptions, verify claims against actual code, classify concerns by severity, and run a pre-mortem. The goal is to find plan-blocking issues before they become implementation-blocking issues.

This skill answers: "Will this plan actually work, and what could go wrong?"

Usage

/challenge-plan [proposed plan, implementation outline, or design decision]
/challenge-plan --scope .work/dev/5096/

• --scope <path>: When provided, read plan.md from the given directory as the plan to challenge, and read goals.md from the same directory for context (success criteria, verified claims, constraints). Use the goals document to evaluate whether the plan actually delivers what was scoped. When --scope is absent, the skill works exactly as it does today (interactive, prompt-driven).
• deep-planning formulates the best approach
• challenge-plan stress-tests the chosen approach
• deep-review evaluates code paths and edge cases after implementation

Checklist

Work through these items in order:

1. Extract assumptions — List every assumption the plan makes (explicit and implicit). These are your attack surface.
2. Verify claims — For each factual claim in the plan (file paths, API behavior, architectural constraints), verify against actual code. Do NOT take claims at face value.
3. Run pre-mortem — "It's 2 weeks from now and this plan failed. Why?" Generate 3-5 realistic failure scenarios.
4. Categorize concerns — Group into: Correctness, Completeness, Performance, Maintainability, and Compatibility.
5. Classify severity — For each concern: Blocking (must fix before implementing), Significant (should fix, risky to ignore), or Minor (nice-to-have, won't derail).
6. Propose alternatives — For each blocking concern, propose a fix or alternative approach. Don't just identify problems — offer solutions.
7. Render verdict — Is this plan ready to implement, needs revision, or should be reconsidered?

Process Flow

digraph challenge_plan {
    "Extract assumptions" [shape=box];
    "Verify claims against code" [shape=box];
    "Run pre-mortem" [shape=box];
    "Categorize concerns" [shape=box];
    "Classify severity" [shape=box];
    "Any blocking concerns?" [shape=diamond];
    "Propose fixes/alternatives" [shape=box];
    "Render verdict" [shape=doublecircle];

    "Extract assumptions" -> "Verify claims against code";
    "Verify claims against code" -> "Run pre-mortem";
    "Run pre-mortem" -> "Categorize concerns";
    "Categorize concerns" -> "Classify severity";
    "Classify severity" -> "Any blocking concerns?";
    "Any blocking concerns?" -> "Propose fixes/alternatives" [label="yes"];
    "Any blocking concerns?" -> "Render verdict" [label="no"];
    "Propose fixes/alternatives" -> "Render verdict";
}

Critical Rules

Extract Assumptions First (Baseline agents skip this)

Before attacking the plan, explicitly list what it assumes. Every plan has hidden assumptions — about the codebase, the runtime, the users, the constraints. These are your primary attack surface.

Examples of hidden assumptions:

• "This API returns headers we can read" — does it?
• "This operation is fast enough to do synchronously" — is it?
• "This cache key is unique" — is it always?
• "Only this code path calls this function" — are there others?

Verify Claims Against Code (Baseline agents partially do this)

For EVERY factual claim in the plan, read the actual code. Plans frequently contain:

• Wrong file paths or line numbers
• Misunderstanding of how a function works
• Incorrect assumptions about decorator behavior
• Missing call sites or consumers

Do NOT take claims at face value. If the plan says "X works this way," verify it.

Record the evidence you used for each verified or disputed claim. Prefer concrete file paths, code paths, or command output over generic statements like "checked the code."

Run a Pre-Mortem (Baseline agents never do this)

Imagine the plan was implemented and deployed, and it failed. Generate 3-5 specific failure scenarios:

• What breaks under load?
• What breaks with edge-case inputs?
• What breaks when another part of the system changes?
• What breaks in a different environment (browser vs Node.js)?
• What breaks when the user does something unexpected?

This is different from listing concerns — it's narrative scenario thinking that surfaces risks pure analysis misses.

Classify Severity (Baseline agents treat everything equally)

Not all concerns are equal. For each concern:

• Blocking: This will cause bugs, data loss, or incorrect behavior. Must fix before implementing.
• Significant: This could cause issues under specific conditions or has notable maintainability cost. Should fix.
• Minor: Nice-to-have improvement. Won't derail the implementation.

This classification is critical — a plan with 10 "minor" concerns is fine. A plan with 1 "blocking" concern is not.

Output Format

## Plan Challenge: [Plan Name]

### Assumptions (attack surface)

1. [Assumption] — Verified: [yes/no/partially]. Evidence: [file:line, code path, or command output]
2. ...

### Pre-Mortem Scenarios

1. **[Scenario name]**: [What happens, why, impact]
2. ...

### Concerns

| #   | Category     | Severity    | Concern | Evidence                             | Fix            |
| --- | ------------ | ----------- | ------- | ------------------------------------ | -------------- |
| 1   | Correctness  | Blocking    | [issue] | [file:line or code path]             | [proposed fix] |
| 2   | Completeness | Significant | [issue] | [file:line or code path]             | [proposed fix] |
| 3   | Performance  | Minor       | [issue] | [benchmark, call path, or rationale] | —              |

### Verdict

[Ready / Needs Revision / Reconsider]

[2-3 sentence summary: what's the biggest risk, what must change, is the direction right?]

If you found no blocking or significant concerns, say so explicitly and summarize what you verified plus the residual risks.