aria-knowledge

/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.

Runtime Gate (per ADR-094)

Canonical resolution: This is the Claude Code variant. When both plugin-claude-code and plugin-claude-cowork are loaded in the same session (most common in Claude Desktop), bare /prospect resolves to this skill — aria-knowledge (Code) is the canonical owner of all 24 dual-port skills per ADR-094 §Part 1. The Cowork variant is namespaced-only: /aria-cowork:prospect.

Before Step 0: Check that the Bash tool is available in this session. If Bash is NOT available (you are running in Claude Cowork or another non-Code runtime), surface the following notification and wait for explicit user confirmation:

⚠️ Runtime mismatch — you invoked aria-knowledge's /prospect from a non-Code runtime.

Behavior is largely the same in both runtimes; for the Cowork-native variant (skips Step 11 CODEMAP/STITCH surfacing per ADR-005, uses in-memory dedup instead of /tmp/ ledger), use /aria-cowork:prospect.

Use /aria-cowork:prospect instead? (y / n)

Wait for an explicit reply:

• y / yes — Use the Skill tool to invoke aria-cowork:prospect with the same arguments the user provided to this invocation. Do not proceed with this skill's steps; the cowork variant takes over and runs to completion. This is the default-yes path — auto-redirect is the helpful action.
• n / no — Proceed with this (aria-knowledge) variant anyway despite the runtime mismatch. The user has explicitly opted in.
• No response / any other reply — Treat as "do not proceed" and exit cleanly without running either variant.

This gate applies even when mode = auto per ADR-094 §Part 3. Auto mode's "implicit-yes on all gates" rule is suspended for the runtime-mismatch check — auto trusts that the user invoked the correct variant, and this gate enforces that precondition. All other auto-mode gates remain bypassed. The friction cost is now low: on y, the auto-redirect runs the correct variant with the original args.

If Bash is available, proceed to Step 0.

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 Linear 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 | | linear | /prospect linear <id> | --linear <id> | Read the ticket's Technical Intake (and Product Intake for goal context) via Linear MCP. If MCP unavailable, ask 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, --linear, --branch, --todos, --session) remain accepted indefinitely. Both /prospect linear LINEAR-123 and /prospect --linear LINEAR-123 resolve identically.
• Modifier flags (apply to any scope): --linear-post (post the prospect verdict to detected Linear tickets at end), --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 Linear-style ticket IDs. If found AND Linear MCP is available, fetch each ticket's Product/Technical Intake + acceptance criteria to use as the goal-anchor in §4.6. If Linear 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 instead, which is calibrated for already-written changes." Continue if user confirms.

Step 0.5: Active Knowledge Surfacing

If the user's config (~/.claude/aria-knowledge.local.md) has active_knowledge_surfacing: true (default as of v2.15.0), surface relevant tagged knowledge BEFORE Steps 1-3 so loaded files inform pattern selection and evidence sourcing. If the field is false, skip this step entirely (note Active surfacing: disabled in the Anchor block).

Algorithm:

1. Build query. Combine, separated by spaces: the Goal sentence from Step 0; the plan's first heading or the first 3 TodoWrite items; any detected Linear ticket IDs (e.g., LINEAR-123); the file basename if scope is file; the branch name if scope is branch.

1. Read the index. Read <knowledge_folder>/index.md (resolve <knowledge_folder> from the config's knowledge_folder field). Parse the ## Tag Index section for ### tagname headers — that's the matching vocabulary (~77 known tags as of v2.15.0). Ignore the ## Other Tags section (freeform tier, intentionally excluded from auto-surfacing).

1. Tokenize. Lowercase the query, strip punctuation to spaces, dedupe to a word set.

1. **M