/plan

description: "Generate an implementation plan grounded in active wiki research. Reads the knowledge base, interviews you about requirements, fills gaps with targeted research, and produces a phased plan with architecture decisions citing wiki articles as evidence."
argument-hint: "<what to build> [--wiki <name>] [--with <wiki>...] [--include-archived] [--local] [--quick] [--no-interview] [--no-research] [--format rfc|adr|roadmap|spec]"
allowed-tools: Read, Write, Edit, Glob, Grep, Bash(ls:*), Bash(wc:*), Bash(date:*), WebFetch, WebSearch, Agent

Your task

**Resolve the wiki.** Do NOT search the filesystem or read reference files — follow these steps: 1. Read `$HOME/.config/llm-wiki/config.json`. If it has `hub_path`, expand leading `~` only (not tildes in `com~apple~CloudDocs`) and prefer that path; use `resolved_path` only as a fallback cache when the expanded `hub_path` is unavailable and `resolved_path` is initialized. If config has only `resolved_path`, use it. If the configured path can be statted but reading `wikis.json` or listing `topics/` fails with `Operation not permitted`, stop and ask the user to grant Full Disk Access/iCloud Drive access to the launcher; do not fall back to `~/wiki` or `resolved_path`. Do not write machine-specific `resolved_path` into shared configs. 2. If no config → read `$HOME/wiki/_index.md`. If it exists → HUB = `$HOME/wiki`. If nothing found, ask the user where to create the wiki. 3. **Wiki location** (first match): `--local` → `.wiki/` in CWD; `--wiki <name>` → `HUB/wikis.json` lookup with portable path resolution (`<HUB>`, `~`, absolute, or HUB-relative); if the registry path is stale, fall back to `HUB/topics/<name>`; CWD has `.wiki/` → use it; else → HUB. 4. Read `<wiki>/_index.md` to verify. If missing → stop with "No wiki found (or no articles). Run `/wiki init` and `/wiki:research` first to build a knowledge base."

Generate an implementation plan for what the user wants to build, grounded in the wiki's accumulated research. Follow the 6-stage pipeline below.

Inventory awareness: use active inventory records as planning constraints when they are relevant to the goal, especially blocked tasks, candidate corpora, open questions, and watch items. If the plan creates a durable work queue, suggest inventory records or a saved inventory view and show a sample before creating them. Keep project rationale in `WHY.md`; inventory is for trackable items and next actions.

Parse $ARGUMENTS

• **goal**: What to build — everything that is not a flag. This is the planning objective.
• **--wiki <name>**: Target a specific topic wiki as the primary knowledge source (subject matter)
• **--with <wiki>**: Load a supplementary wiki as additional context. The primary wiki provides **domain knowledge** (what to build); `--with` wikis provide **craft/skill** knowledge (how to build it, writing techniques, design patterns). Multiple `--with` flags allowed.
• **--local**: Use project-local `.wiki/`
• **--include-archived**: Explicitly allow archived primary or supplementary

wiki context. Label archived-derived constraints/sources in the plan.

• **--quick**: Skip interview and gap research — produce a plan directly from wiki content (Stage 1 → Stage 5)
• **--no-interview**: Skip the interview stage (Stage 2)
• **--no-research**: Skip gap research (Stage 3) — plan only from existing wiki content
• **--format**: Output structure. One of:
• `roadmap` (default) — phased implementation plan with timeline
• `rfc` — Request for Comments format (Google/Uber style: context, goals, design, alternatives)
• `adr` — Architecture Decision Record (context, decision, consequences per choice)
• `spec` — Technical specification (architecture, APIs, data models, testing)

---

Stage 1: Context Assembly

Read the wiki deeply to understand what knowledge exists about the planning goal.

1. **Read master `_index.md`** — scan all articles for relevance to the goal 2. **Read ALL category `_index.md` files** — concepts, topics, references 3. **Grep the wiki** for key terms from the goal (synonyms, related concepts) 4. **Read all relevant articles in full** — follow See Also links, read cited raw sources 5. **Read sibling wiki `_index.md` files** — check if related knowledge exists elsewhere 6. **Load `--with` wikis** (if specified): For each supplementary wiki, look up in `HUB/wikis.json`, read its `_index.md` and relevant articles. These provide craft/skill context — techniques, patterns, best practices to apply when generating the plan.

Archived primary or supplementary wikis are rejected unless `--include-archived` is present. Deep context assembly may mention archived index matches as a separate note, but archived material should not shape the plan unless explicitly included.

Produce a **context summary**: what the wiki knows about this topic, organized by:

• **Directly relevant**: articles that address the goal head-on
• **Supporting context**: articles that inform design decisions
• **Gaps identified**: what the goal needs that the wiki doesn't cover

Present the context summary to the user before proceeding:

📚 Wiki knowledge for "{goal}":

Directly relevant (N articles):
- [Article 1](path) — what it contributes
- [Article 2](path) — what it contributes

Supporting context (N articles):
- [Article 3](path) — relevant because...

Knowledge gaps:
- Gap 1: The wiki doesn't cover X, which we'll need for this plan
- Gap 2: Y is mentioned but not in enough detail

Proceeding to interview...

---

Stage 2: Interview (skip if `--no-interview` or `--quick`)

Ask the user 3-7 clarifying questions to surface requirements, constraints, and edge cases that the wiki doesn't address. These questions should be **informed by the wiki content** — don't ask about things the wiki already answers.

Good interview questions:

• Constraints the wiki can't know: "What's the timeline? What's the budget for dependencies?"
• Scale parameters: "How many articles/sources a