planlisted

Set the next goal, and keep the release list — `WSS.record.roadmap` holds the goals and splits by lane, `WSS.record.releases` holds the milestones, their versions and their marks. Marking one authorises `--wss-release` to tag. SHORTHAND: `--wss-plan`. Also on "what should we build next", "what's next for the UI", "is this milestone done", "reorder the roadmap".
qupunto/wss · ★ 1 · Web & Frontend · score 72

Install: claude install-skill qupunto/wss

# Goals, and the release list This skill is the sole writer of two records, and the split between them is the thing to hold onto: | Record | Holds | Splits by lane | |---|---|---| | `WSS.record.roadmap` | **Goals.** What an area of work is trying to achieve, the blocks that get it there, their order. In that area's own terms. | **yes** | | `WSS.record.releases` | **The release list.** One entry per milestone: the version it intends to ship as, which goals it comprises, whether it is marked completed. | **never** | **No roadmap carries a version number or a completion mark.** Not a lane's, not an unsplit project's. That single prohibition is what lets a project hold any number of lane roadmaps while still holding exactly one release checkpoint — `--wss-release` reads `WSS.record.releases` and no other planning record. [`WSS.RECORD-CONTRACT.md`](../../wss/workflow/WSS.RECORD-CONTRACT.md) holds the rule and the reasoning; `wss-doctor.sh` fails on a roadmap that breaks it. A roadmap is **not** a task list and **not** a place for design arguments. The checklist is `WSS.record.todo` and the reasoning is `WSS.record.decisions`, both `--wss-todo`/`--wss-log`'s. **Project facts come from `.claude/WSS.WORKFLOW.json`**: `WSS.record.roadmap`, `WSS.record.releases`, `WSS.record.todo`, `WSS.record.openDecisions`, `WSS.record.decisionsIndex`, `WSS.record.stocktake`, and `WSS.agents.roadmap`. Without a manifest, fall back to `WSS.ROADMAP.md` and `WSS.RELEASES.md` and say so. Where a `.c