spec-revisionlisted

# spec-revision Review a technical specification, round after round, until it can be implemented without guessing: free of contradictions, ambiguities, and gaps that would force an implementer to invent an answer. You orchestrate; `dev-loop:reviewer` agents judge, one per group, against the criteria file this skill owns. The writing happens here, on the main thread. ## 1 — What you are given Priority order: an explicit path, the last spec-shaped file discussed, or text pasted inline. If none, ask the user rather than invent the content. This skill checks **what has to be built**; **how it gets built** is `/dev-loop:plan-revision`. ## 2 — Frame the document Before criticising, understand the **type** (API, feature, architecture, functional requirements), the **project context** (stack, domain, constraints) and the **current structure** (sections, format, detail level). This framing matters because the same sentence weighs differently by type: "fast" is a tolerable ambiguity in a vision note and a blocker in an API spec with latency requirements. **If the document builds inside an existing project, open it, read its conventions, and keep Grep on the shared helpers.** If the code is out of reach, **say so in the report**: that part stays uncovered, approved knowing it rather than believing it done. ## 3 — Cut into groups A document too large for one sitting is reviewed group by group — the signal, the cut, and what each group is entitled to are held by `${CLAUDE_PLUGI