make-plan — Phase 1: Plan & Specify (stops at review)

The user gives a goal in plain language. You turn it into reviewable artifacts — proposal, design, delta specs, tasks, and ADR(s) for the significant decisions — then STOP and hand them to the user/reviewer. You do not implement production code here; that is /implement-specs (Phase 2), which runs after the specs and ADRs are approved.

How hard you interrogate depends on how clear the task is — clear tasks get a light pass, fuzzy tasks get grilled. Always announce the lane and let the user override.

Sub-skills you compose (Skill tool or slash command):

• grill-me — interview the user to firm up an unclear plan
• openspec-explore / /opsx:explore — think through a fuzzy/large problem
• openspec-propose / /opsx:propose — generate proposal + design + delta specs + tasks
• task-analyzer / dev-workflows:technical-designer — size up the task and author ADRs / Design Docs

Step 0 — Resume check (always first)

openspec list --json

• Change for this goal exists with specs but not yet implemented → it's already planned; tell the user to run /implement-specs (don't redo planning). Offer to revise the specs if they want.
• Change in progress with code / partial tasks → planning is done; point them to /implement-specs to continue.
• Archived → done; ask if this is a new follow-up goal.
• Otherwise → start fresh at Step 1.

Step 1 — Assess clarity, pick the lane

Rate the goal and announce the rating + lane before doing anything. Base it on: are requirements/constraints concrete? is there an existing spec/code precedent? how big is the blast radius?

• State it plainly: "Rating this 🟡 — I'll ask a few questions, propose, write ADRs for the key decisions, then stop for your review."
• User can override anytime ("go light" → 🟢; "grill me hard" → 🔴).
• When unsure between two lanes, pick the more cautious one — planning is cheap, a wrong spec is expensive.

Step 2 — Clarify (lane-dependent)

• 🟢 → skip.
• 🟡 → grill-me, kept short (only genuinely open decisions; anything answerable from the codebase, read the codebase instead).
• 🔴 → /opsx:explore to map the problem, then grill-me thoroughly until shared understanding.

Step 3 — Propose

Run openspec-propose / /opsx:propose "<goal, enriched with what you learned>" to scaffold the change and generate proposal/design/delta-specs/tasks.

Step 4 — ADRs for the significant decisions

For each architectural / cross-cutting / hard-to-reverse decision the change makes, record an ADR (context → decision → alternatives considered → consequences). Use dev-workflows:technical-designer / documentation-criteria for the format.

• Location: if the repo already uses docs/adr/, add docs/adr/NNNN-<slug>.md there; otherwise capture them in a ## Decisions (ADR) section of the change's design.md.
• Scope by lane (table above). Don't manufacture ADRs for trivial 🟢 changes — a one-line note in design.md is enough.

Step 5 — Review the existing code the change will touch (find issues up front)

Before locking the plan, code-review the existing code in the area this change will modify or build on — so the specs/ADRs account for real bugs, tech-debt, risky coupling, and reusable pieces instead of discovering them mid-build. Use the dev-workflows:code-reviewer agent or the fullstack-dev-skills:code-reviewer / built-in code-review skill, whichever is present (skip only if there's genuinely no existing code to touch — a greenfield area). Point it at the relevant files (find them via Grep/Explore) and the project CLAUDE.md.

• Fold its findings into the plan: a ## Existing-code risks section in proposal.md (or design.md), an ADR if a finding forces a design decision, and concrete cleanup items in tasks.md when they're in scope.
• Do not fix code here (this is still Phase 1, no production code) — record the issues so the reviewer sees them and /implement-specs handles them.

Step 6 — Recommend the implementation experts (record, don't run)

Analyze the task — reuse task-analyzer's output if it dispatched here, otherwise run its §3 Size (essence, type, scale, tags & experts) now — plus the stack (host CLAUDE.md / package.json / ORM schema / file types), then recommend the tech-expert skills that /implement-specs should use to code — so the reviewer sees them too.

• Discover from skills actually present in this environment (e.g. fullstack-dev-skills:nestjs-expert, :postgres-pro, :react-expert, :typescript-pro, nextjs-developer, :test-master). Never name an unavailable skill.
• Pick a primary + 0–2 supporting (≤3 total), one line of reasoning each.
• Write the recommendation into the change (a ## Implementation experts note in design.md or tasks.md) so /implement-specs can pick it up.

Step 7 — STOP for review (the hand-off)

Do not start coding. Present a tight review package and stop:

• What to review: proposal.md, the delta specs, tasks.md, and the ADR(s) — with their paths.
• The recommended experts.
• Any open question the reviewer must settle.
• Closing line: "Specs + ADRs are ready for review. Once approved, run /implement-specs to build (spec-loop will code → review → fix until it matches)."

Guardrails

• Phase 1 only. NEVER write production code in /make-plan — that belongs to /implement-specs. (Scaffolding the OpenSpec artifacts + ADR docs is expected; application/source code is not.)
• Announce the lane and each phase transition in one line.
• Honest about open questions — surface ambiguities for the reviewer instead of guessing.
• Respect the host project's CLAUDE.md conventions.
• One goal at a time.