release-reviewlisted

Run a comprehensive pre-release review of a whole product, working through every command, parameter and config surface with the user, one item at a time. Rulings are collected in an on-disk changes ledger, ruled batches are handed to parallel implementer sessions as soon as they are ready, and the programme is sequenced through code-quality review, docs review, QA and release, then harvested into the repo's docs. Resumable across sessions. Use when the user says "get this to 1.0", "release review", "final review of all commands and params", "review the whole product before release", "comprehensive review of full functionality", "pre-release review", "resume the release review", or "where are we in the review". Do NOT use for reviewing a diff or PR (use code-review), QA of one feature (use qa), a persona-based product audit (use review-product), or executing an already-written plan (use longshot).
nielsmadan/skills · ★ 1 · Code & Development · score 77

Install: claude install-skill nielsmadan/skills

# Release Review Bring an existing product to a reviewed, consistent, documented and exercised release. This is a **review programme**: its output is a polished surface over the features that already exist. The user rules on every change. Implementation runs in parallel sessions or in longshot, not in the reviewing conversation. ## Instructions ### Step 0: Start or resume Look for an existing programme directory. Use the repo's scratch plan directory if one exists (e.g. `docs/superpowers/`), otherwise `docs/release-review/`. Run `git check-ignore <dir>`, tell the user whether it is ignored, and let them decide whether it should be. - **Programme exists:** read `programme.md`, then `changes.md`. Print the **Now** / **Next** lines and the in-flight batches. Check `git log` for commits reported by implementer sessions since the last update, and mark those entries `implemented`. Then continue from **Now**. Do not re-ask framing questions. - **A review started under another workflow** (a release spec plus a findings or changes document, e.g. from a brainstorming session): adopt it rather than starting over. Write `programme.md` with its framing and the current position, and link the existing spec and ledger as the source of truth instead of copying them. Confirm the position with the user. - **No programme:** go to Step 1. Formats for every file are in `references/