/prospect

description: "Run a structured pre-mortem on a plan or approach BEFORE execution. Per-step risk enforcement, active evidence-sourcing pass (autonomous lookups + targeted user-asks for anything that could become objective), simpler-alternative discipline, plan-formation diagnosis, action verdicts (PROCEED/SHRINK/SPLIT/DEFER/KILL), and a growing failure-mode pattern library. Triggers: '/prospect' (defaults to plan scope), '/prospect plan', '/prospect session', '/prospect todos', '/prospect file {path}', '/prospect ticket {id}', '/prospect branch {name}'. Backward-compat flags and legacy 'linear' spellings still accepted. (Code port — ADR-094.)"

/prospect — Plan pre-mortem with risk enforcement

Run a structured pre-mortem on a plan or approach that has been *created but not yet executed*. Forward-looking counterpart to `/retrospect`. Produces a 10-section markdown report with per-step verdicts, risk status, action recommendations, and process pre-mortem when the plan-formation itself was thin. Writes findings to `knowledge/logs/prospect/` and runs aria's standard intake.

The discipline this enforces: before the first edit lands, every planned step gets named, its evidence base examined, its smallest viable version identified, and its action gated on the strength of the underlying hypothesis. Mirrors `/retrospect`'s shape so the same review muscle works in both directions.

When to use

• After a multi-step plan is articulated (in chat, in TodoWrite, in a `.md` plan file) but no code has been written yet
• After `/brainstorming` concludes with an action plan
• After `/distill` produces a task spec that's about to be executed
• After a ticket's Technical Intake is drafted and the implementer is about to begin
• Before kicking off a long autonomous run (e.g., `combined go`) on a non-trivial plan
• As a soft-suggested response to "let me implement…", "I'll just code it…", "ok ship it" when no validation exists yet

If code has already been written/committed (even in-session), use `/retrospect` instead — that pivots from forward-looking to backward-looking validation.

Step 0: Inputs & Mode Detection

Parse the invocation arguments. The first positional argument is the **scope keyword**; subsequent positional arguments are scope-specific. Six scopes plus a no-args default:

| Scope | Trigger | Backward-compat flag (still accepted) | Plan source | |---|---|---|---| | **plan** (default) | `/prospect plan` or `/prospect` | (was the no-arg default) | Current conversation's articulated plan — combine the active TodoWrite list, the most recent assistant plan/approach message, and any in-session plan file Claude has written. If ambiguous, ask user "Which of these is the plan you want me to pre-mortem?" with a short list. | | **session** | `/prospect session` | `--session` | Synonym for **plan**. Reserved for cases where the user wants to emphasize "everything articulated this conversation" rather than a single plan artifact. | | **todos** | `/prospect todos` | `--todos` | Just the active TodoWrite list — a thin mode for quick checks | | **file** | `/prospect file <path>` | `--plan <path>` | Read the markdown file at `<path>` as the plan | | **ticket** | `/prospect ticket <id>` | `--ticket <id>`, `linear`/`--linear` (legacy) | Read the ticket's Technical Intake (and Product Intake for goal context) via the connected project-tracker MCP — Linear, Jira/Atlassian, Asana, Monday, ClickUp, Notion-as-tracker, GitHub Issues. If no tracker MCP is connected, ask the user to paste. | | **branch** | `/prospect branch <name>` | `--branch <name>` | Uncommitted/unpushed local changes on the branch — `git diff <main-branch>...<name>` — treated as a plan-in-progress (NOT shipped yet) |

**Argument parsing rules:**

• If the first positional arg matches a scope keyword (case-insensitive), use it. Otherwise treat it as an arg to the default `plan` scope.
• Backward-compat flag forms (`--plan`, `--ticket`, `--branch`, `--todos`, `--session`) remain accepted indefinitely. Both `/prospect ticket ABC-123` and `/prospect --ticket ABC-123` resolve identically.
• **Legacy vendor spellings still work.** The `ticket` scope was named `linear` before the surface was made tracker-agnostic, so `/prospect linear <id>` and `--linear <id>` resolve exactly as `ticket`/`--ticket` do, and `--linear-post` resolves as `--tracker-post`. They are aliases, not separate behaviour — never advertise them as the canonical form.
• Modifier flags (apply to any scope): `--ticket-post` (post the prospect verdict to detected tickets at end; alias `--linear-post`), `--no-source` (skip Step 3.5's Evidence-Sourcing Pass), `--lens=overbuild` (run the over-build review pass — see "Over-build lens" section; opt-in, off by default).

After mode detection, gather:

1. **Goal** — Ask the user: "What is this plan supposed to accomplish? (One sentence is fine.)" If they don't reply, fall back to the plan's first heading or stated objective. 2. **Tickets** — Scan plan text/commits/branch name with regex `\b([A-Z]{2,}-\d+)\b` for ticket IDs (the pattern is vendor-neutral — it matches DEV-123, PROJ-45, JIRA-9 alike). If found AND a project-tracker MCP is available, fetch each ticket's Product/Technical Intake + acceptance criteria to use as the goal-anchor in §4.6. If a project-tracker MCP is unavailable, note "ticket context unavailable" but continue. 3. **Pre-execution evidence** — Ask the user: "For each step in this plan, do you have evidence the step is necessary and that the underlying assumption is correct? (✅ measured / ⚠ inferred / ❌ contradicted / ❓ untested)" Show the per-step list and accept inline replies. If user can't supply evidence for any step, mark those ❓ — those steps will resolve to DEFER unless §4.7 produces supporting hypothesis confidence.

If scope is `branch` (or invoked via `--branch`) and the diff is non-trivial (>50 LOC across >3 files), warn: "Branch already has substantive code — consider `/retrospect range main..HEAD