plan-initlisted

# Plan Init Run a structured planning conversation and produce a complete `plan.md` for a new project. The goal is to surface all architectural decisions *before* writing the plan, so the document is correct on the first pass rather than requiring a review cycle to patch gaps. ## Greenfield check Before walking through the 7 conversation phases, confirm this is a **greenfield** project. Run `git log --oneline | head -1` in the project directory — if it returns any commit, STOP and recommend `/plan-feature` instead. `/plan-feature` reads the existing codebase before drafting; `/plan-init` does not, and using it on a project with committed code risks proposing data models that conflict with the live schema (Phase 2 entities, Phase 4 stack choices get answered from imagination rather than from the existing producing files — see plan-init deep-dive investigation #17). `/plan-init` is for wholly new projects with no committed code, no schema, and no existing module structure. If uncertain (e.g., the directory has stray files but no real codebase), ask the operator to confirm "greenfield" before proceeding. ## Pipeline position `/plan-init` is Step 1 of the plan pipeline: `plan-init or plan-feature → plan-review → plan-wrap → repo-sync → build-phase`. Always run `/plan-review` and `/plan-wrap` on the produced plan BEFORE `/repo-sync` mints GitHub issues — a gap caught after sync is an **N+1-edit** problem (1 plan-doc fix + N issue-body edits in GitHub to keep the sync intact),