phase-wireframelisted

One wireframe in, one wireframe per phase out. Each phase file shows everything available **by** that phase and nothing that isn't, in exactly the positions the approved design already put them — so a phase wireframe is the real build target for that release, not a redrawing of it. ``` base.html ──┬──► phase-1/base.html only what ships in phase 1 ├──► phase-2/base.html phase 1 + phase 2 └──► phase-3/base.html phase 1 + 2 + 3 ( = the base, if phases cover it all ) ``` **Subtract only.** Nothing is moved, resized, restyled or repositioned; nothing new is invented. That is the entire discipline of this skill, and §4 proves it mechanically rather than trusting the eye. ## 1 · Resolve the two inputs **The base wireframe** — one self-contained HTML file. If the user hasn't named one, ask; don't guess among the files in `design/`. Never work from an already-phased file: every phase is cut from the original. **The phases, and what belongs to each.** In priority order: 1. A **story map** (`*.json` from `/vstack:user-story-map`) — `phases[]` gives the order and goals, `stories[]` give what lands when. This is the best input; ask for one if a story map exists. 2. A **spec** with P1/P2/P3 priorities, or a roadmap. 3. **The user tells you** the phases in the conversation. If none of those exist, stop and ask — inventing a release plan is not this skill's job. ## 2 · Write the phase plan before touching any HTML Open the base and inventory **e