reviewlisted

Use when the user asks for a findings-first review or asks you to review and advise — on a branch, pull request, worktree, staged diff, or fixed-point diff, or on a written artifact such as a plan, design doc, handoff note, spec, or proposal — against repo standards, specs, and regression risk. Do not use to implement a fix, run a test campaign (use qa), diagnose one bug (use diagnosing-bugs), or audit runtime efficiency (use deep-audit).
espensev/ai-skills · ★ 0 · Code & Development · score 72

Install: claude install-skill espensev/ai-skills

# Review - Change and Document Audit Review changed work, or a written artifact, without modifying any source file. Produce a findings-first audit that separates documented-standard violations, spec mismatches, and regression risks. **Output:** `docs/reviews/review-{date}-{slug}.md` **Default command:** `$review` **Source edits:** none --- ## Commands | Command | Usage | Purpose | |---------|-------|---------| | `branch` | `$review` or `$review <fixed-point>` | Review `HEAD` against a fixed point, usually the default branch merge-base | | `working` | `$review --working` | Review unstaged and staged working-tree changes | | `staged` | `$review --staged` | Review only staged changes | | `spec` | `$review --spec docs/spec.md <fixed-point>` | Review against an explicit spec source | | `doc` | `$review --doc <path>` | Review a written artifact — plan, design doc, handoff note, spec, or proposal | Default to `branch` if no command is supplied. If the user names a document, plan, or handoff instead of a ref — "review and advise on this plan", "read the handoff and review it" — use `doc` with that path. --- ## Review Principles - Findings lead the report. Summaries and praise come after issues, never before. - Every finding must cite concrete evidence: `file:line`, diff hunk, command output, or a quoted spec/standard line. - Separate axes in the analysis: - **Standards:** documented project conventions, coding standards, and repo instructions. - **Spec:** explicit