prospect

/prospect — Plan pre-mortem with risk enforcement (cowork variant)

Run a structured pre-mortem on a plan or approach that has been created but not yet executed. Forward-looking counterpart to /aria-cowork: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_folder>/logs/prospect/ and runs aria's standard intake.

Cowork variant of aria-knowledge's /prospect. Output schema (10-section report shape, frontmatter, logs/prospect/ destination) byte-identical per #18a + #18g + #18h. Two input-discovery divergences:

• Step 11 Tracked artifacts surfacing (CODEMAP/STITCH) SKIPPED per ADR-005 + #18f. aria-knowledge surfaces CODEMAP directory + STITCH file for the plan's project as Step 11. Cowork excludes /codemap + /stitch skills, so this step is dropped entirely. Plan-quality verdict in cowork doesn't depend on codebase-structure validation.
• Step 0.5 ledger uses in-memory dedup if /tmp/ is not writable (#18d). aria-knowledge's Step 0.5 Active Knowledge Surfacing dedups against /tmp/aria-active-{session_id} to avoid re-Reading files already surfaced by hooks in the same session. Cowork has no hook layer (no upstream surfacing to dedup against), and Cowork's sandbox may restrict /tmp/ writes — cowork falls back to in-skill in-memory dedup when ledger file ops fail.

Step 0.5 Active Knowledge Surfacing skill-side logic ports byte-faithfully per #18c (10-substep query-build → tokenize → match → load → summarize). Evidence-Sourcing Pass (Step 3.5) ports byte-faithfully per #18e. Failure-mode pattern library reads/writes shared rules/prospect-patterns.md per #18i (cross-plugin compatible).

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 Cowork variant — namespaced-only. When both plugin-claude-code and plugin-claude-cowork are loaded in the same session (most common in Claude Desktop), bare /prospect resolves to aria-knowledge's variant — Code is the canonical owner of all 24 dual-port skills per ADR-094 §Part 1. To reach this skill, use the namespaced form: /aria-cowork:prospect. Do NOT match bare /prospect — that belongs to aria-knowledge.

Before Step 0: Check whether the Bash tool is available in this session. If Bash IS available (you are running in Claude Code or another runtime with shell access), surface the following notification and wait for explicit user confirmation:

⚠️ Runtime mismatch — you invoked aria-cowork's /prospect from a runtime with shell access.

Behavior is largely the same in both runtimes; for the Code-native variant (includes Step 11 CODEMAP/STITCH surfacing, uses /tmp/ ledger for dedup), use /prospect (the aria-knowledge canonical).

Use /prospect instead? (y / n)

Wait for an explicit reply:

• y / yes — Use the Skill tool to invoke prospect (the bare-slash canonical, which routes to aria-knowledge when both ports are loaded) with the same arguments the user provided to this invocation. Do not proceed with this skill's steps; the aria-knowledge 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-cowork) 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 NOT available (normal Cowork runtime), 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 use