/plan

name: plan
argument-hint: "[topic] [sdd | sources | iso | research]"
description: "Plan a feature or initiative through a computed route: the conductor derives the canon delta and assembles the document package — from a zero-document null route for small fixes to an umbrella PRD with one spec per capability for large initiatives. Expert paths: sdd (full package), sources mode (MRD → BRD → URD) for market research and discovery, iso mode (BRS → StRS → SyRS → SRS) for ISO 29148 and regulated work, research for an investigation that the research instrument closes either by scope coverage (a research document) or by a recommendation (an rnd). Explicit form: plan research. Use for 'plan the X redesign', 'create a roadmap', 'plan a new feature', 'I need market research before we plan', 'we're regulated — start the ISO requirements cascade', 'investigate X before we plan', 'compare the alternatives for Y'. Not for recording a decision or documenting existing code — use /archcore:document. Not for checking docs against code — use /archcore:review."

/archcore:plan

Plan a feature or initiative through a computed route. The conductor (`skills/_shared/delta-routing.md`) derives the canon delta Δ, the gap profile Π, the zone maturity M, and the risk flags R, then assembles the document package; instruments produce the documents. Vision types are the primary output. Reads cover all three categories: vision supplies intent and resumption targets, knowledge supplies constraints, experience supplies precedent.

When to use

• "Plan the auth redesign" → computed route — typically `capability`: one spec plus one plan
• "Create a roadmap for the API migration" → computed route
• "Plan a new feature for CSV export" → computed route
• "Plan the notifications platform" → computed route — typically `umbrella`: prd, one spec per capability, one plan
• "I need market research before we plan" → acquisition instrument (`sources` expert path)
• "We're regulated — start the ISO requirements cascade" → iso links (`iso` expert path)
• "Investigate X before we plan" → research instrument, `research`; "Compare the alternatives for Y" → research instrument, `rnd` — a named pending decision or candidate set selects `rnd`, otherwise `research`
• `plan research <topic>` → research instrument; the instrument selects `research` (closed by scope coverage) or `rnd` (closed by a recommendation) by its closing test

**Not plan:**

• Recording a decision → `/archcore:document`
• Documenting existing code → `/archcore:document`
• Codifying a team standard → `/archcore:document`
• Checking documents against code → `/archcore:review`

Route computation

Apply in this order:

| Signal | Route | |---|---| | The user names a path (`sdd`, `sources`, `iso`, `research`) | The named instrument per the expert invocation map in `skills/_shared/delta-routing.md`, without route computation | | The user names a route | Fix that route; run Derivation to compute its package per `skills/_shared/delta-routing.md` | | Any other request | Compute Δ, Π, M, and R per the Derivation section of `skills/_shared/delta-routing.md`; its route table decides the package | | A decision surfaces at a gate | Record the `adr` through the decision instrument (`skills/_shared/tracks/decision.md`), then return to the open gate |

Research boundary: discovery feeding an `mrd` → `brd` → `urd` requirements chain belongs to acquisition. A request naming a pending decision or a set of candidates to choose between produces `rnd`; any other investigation produces `research`. The path name `research` selects the instrument, not the type; the same test applies. Neither `rnd` nor `evidence` is an entry on this command: an `rnd` comes only from that test, the spike, or the compatibility fallback, and a standalone material is filed through `/archcore:document evidence`. A request proposing a specific target for team acceptance ("should we switch to Y", "let's adopt Y") belongs to `/archcore:document`'s decision instrument.

Execution

1. Ground

Complete this step before asking the user any question. The research vocabulary probe (`skills/_shared/research-compatibility.md`) runs only under its own condition 1 — a request or type naming `research` or `evidence`, a route engaging the research instrument, or a grounding result of either type. Add `research` and `evidence` to the planning-moment filter below only when the probe returns `yes`; a topic search without a type filter finds documents of both types on every engine. If this skill has no shell tool, use the probe result the host supplied; if none was supplied, report `needs-vocabulary-probe` with the helper path and stop before the first MCP call that names either type.

1. Search `.archcore/` with `mcp__archcore__search_documents` and `mcp__archcore__list_documents` across all three categories. Pass a planning-moment type filter — for example `types=["idea", "prd", "plan", "spec", "rnd", "rfc", "adr", "rule", "task-type", "cpat"]` — instead of relying on the global type ranking. Do not exclude a category from reads. 2. WHEN a found document carries `implements` or `related` relations, pull the linked documents one hop via `mcp__archcore__list_relations` and `mcp__archcore__get_document`. 3. WHEN a found draft on the topic carries an `archcore:track` state block, resume it per the resume rules in `skills/_shared/gate-contract.md` and `skills/_shared/delta-routing.md` instead of opening a new track. 4. Read git state — current branch, recent commits, working tree — and the code areas the topic names. Record the concrete files and modules for Step 5, and note zone documents whose referenced paths changed after them — the staleness input to Derivation. 5. IF `.archcore/` exists but contains no documents, THEN proceed on outer-context grounding (git state and the codebase) and report that zero documents were found. 6. IF `.archcore/` does not exist, THEN announce initialization in one line and call `mcp__a