Plan Proposal

plan-proposal

Orchestrates the planning phase of an OpenSpec change on develop. Composes existing skills — it does not reimplement them. Twin of ship-it, which owns the implementation phase inside the worktree. The two split at the git-worktree boundary, which is also the interactive/headless line.

flowchart LR
  subgraph Planning ["PLANNING — develop, human present"]
    A["new/ff/continue"] --> B["doubt-review"]
    B --> C["scenario-design + category-fold + manifest"]
    C --> D["plan-proposal (this skill)"]
  end
  D -->|"boundary: commit + spawn worktree"| E["ship-it"]
  subgraph Implementation ["IMPLEMENTATION — worktree"]
    E
  end

Hard constraint — main session only (never a subagent)

plan-proposal MUST run in the main interactive session. It invokes doubt-driven-review (which spawns a fresh-context reviewer, and a second cross-model reviewer — automatically when a @propose-review-N role resolves, offered interactively only when none does; nested subagent spawn is blocked) and scenario-design (whose proposal/design-stage HARD gate calls ask_user). Both need a live main session.

Guard: if you detect you are running inside a subagent context (nested reviewer spawn would be blocked, or ask_user is unavailable), STOP and surface: "plan-proposal must run in the main session — doubt-review and the scenario-design gate cannot run nested. Re-invoke from the main session on develop." Do not degrade the doubt-review to a self-questioning fallback.

Preconditions

• On the develop branch (planning happens on develop; the worktree is spawned from the planning commit).
• openspec CLI available; resolve the change name from --change <name>, the conversation, or openspec list --json (ask if ambiguous).
• Announce: "Planning change: <change> (override with /plan-proposal <other>)."

Procedure

1. Ensure planning artifacts exist

Bring the change to a drafted state using the existing generated skills — do not hand-roll the directory:

• No change dir yet → openspec-new-change (or -ff for the fast path).
• Partial artifacts → openspec-continue-change.

State in the drafting request: "plan-proposal is driving this change". The openspec/config.yaml rules.tasks rule sees it and skips its "Run plan-proposal now?" confirm (no re-entry). rules.proposal may still offer pending mockups while proposal.md is written — that is expected; Step 1b only re-offers rows not declined.

Artifacts live at openspec/changes/<change>/: proposal.md, design.md (when the change warrants one), specs/**/spec.md, tasks.md.

Cite code claims in design.md. Instruct the author to cite the path (and :line when the statement is line-specific) for every statement in design.md about existing code behaviour — e.g. packages/server/src/pi-core-checker.ts:42. Not gated: a citation makes a wrong-file or "does not exist" claim cheap to spot before review.

1b. Adopt pending mockups (idempotent backstop)

Backstop for direct entry, -continue on an existing proposal, re-runs, and SHIP_IT_BLOCKED hand-backs. Runs after the artifacts exist, before doubt-review, so reviewers and scenario-design see the mockup at its final path.

1. Collect every root mockups/AGENTS.md row whose Purpose cell ends with Pending change: <intent>, minus rows that also carry See change: (owned by a change — never offered), minus rows already declined in this session (including a decline in the rules.proposal multiselect during Step 1).
2. None left → ask nothing, change nothing, go to Step 2.
3. Otherwise ONE ask_user multiselect offering every remaining row; the user matches, you do not judge similarity. Unchosen rows count as declined.
4. Adopt each chosen entry with the mechanics of the explore-mockup-adoption requirement (canonical, same as rules.proposal): File cell must resolve to an entry directly under mockups/ (else skip + report); mkdir -p <changeDir>/mockups; refuse if <changeDir>/mockups/<entry> already exists; git mv (tracked) / mv (untracked), never copy; only after a successful move — recompute outward relative links, remove the row, add Mockup: mockups/<entry> (in this change) under What Changes in proposal.md. A failed move keeps its row.

An edited proposal.md is "modified in this session" → Step 2 reviews it.

2. Doubt-review proposal.md + design.md (trigger: drafted or modified)

Whenever proposal.md or design.md is created or changed in this session, invoke doubt-driven-review on the changed artifact:

• Pass ARTIFACT + CONTRACT only — never the CLAIM, never your reasoning.
  • ARTIFACT = the proposal/design prose (decompose if large per doubt-review).
  • CONTRACT = the requirements/constraints the artifact must satisfy (the specs deltas, the non-goals, the invariants it asserts).
• Run the spec-collateral scan before each doubt-review cycle (the artifact changes between cycles): node scripts/spec-collateral.mjs --change <change>. Append its output to the CONTRACT under the heading "Candidate conflicting requirements (advisory scan) — check each". The candidates are facts about the corpus, not the CLAIM. If the scan cannot run or exits non-zero, report the failure and proceed with the cycle without candidates — the scan never blocks planning.
• Reviewer prompt hygiene — the reviewer verifies claims against the repository, writes unverified for any claim it cannot check instead of asserting it, and reports every listed candidate the artifact contradicts. A contradicted candidate is resolved by a MODIFIED/REMOVED delta or an artifact correction; "unaffected" is reserved for a verified false positive.
• Cross-model review — runs automatically when a @propose-review-N role resolves; surface the interactive cross-model offer only when none does.
• Reconcile every finding against the artifact text using doubt-review's precedence (contract-misread → actionable → trade-off → noise). When a finding is valid + actionable, PAUSE: the artifact is corrected before proceeding.

Do not fold scenarios until the doubt cycle reaches a stop condition (trivial findings, 3 cycles, or explicit "ship it").