quality-review
Quality Review
Overview
Dispatches one parallel Sonnet agent per bullet point in the ## Implementation Quality section of the nearest AGENTS.md. Each agent independently discovers what changed and checks the codebase against exactly one criterion. A triage pass then removes false positives, duplicates, and contradictions before the final report.
Workflow
1. PARSE → Extract each bullet point from ## Implementation Quality in AGENTS.md
2. DISPATCH → One Task agent per criterion (all in parallel, single message)
3. TRIAGE → Review all raw findings: drop false positives, duplicates, and contradictions
4. REPORT → Compile cleaned findings into summary table
Step 1: Parse Criteria from AGENTS.md
Read the project's AGENTS.md and extract every bullet point under ## Implementation Quality. Stop at the next ## heading — do not include bullets from any other section. Each - line becomes one criterion.
More from reviewstage/stage-cli
stage-chapters
Generate Stage chapters for the current local git branch and open them in a browser for review.
122fixing-ci
Use when CI is failing on a branch and you need to diagnose failures from GitHub, fix them locally with iterative verification, and re-push clean commits.
1trade-off
Use at any stage — planning, before implementing, or reviewing code that's already written — to surface high-level trade-offs that could significantly simplify the work. Scans two layers in strict priority order. First, user-facing behavior (features, flows, states, settings, notifications, undo, real-time, bulk ops) — cutting a behavior removes the architecture and code behind it. Second, architectural design (queues, caches, background jobs, new packages, new tables, new services, streaming, real-time infra) — cutting an architectural piece removes whole categories of implementation. Stops there; code-level simplification is outside scope. Proactively invoke whenever the scope of a task looks like it could grow, whenever you catch yourself about to add a queue, cache, new package, new table, new service, or behavior that wasn't explicitly requested, or when looking back at a recent diff that feels larger than the task warranted.
1linear-issue
Use when creating a Linear issue from the current coding context, or when the user invokes /linear-issue. Infers team, priority, status, and relationships from conversation context, working directory, and git branch.
1deslop-ui
Use when building or reviewing UI components, pages, or layouts to ensure premium, intentional design that never looks vibe coded
1iterate-pr
Use when a PR is open and the user wants to autonomously monitor and fix PR review comments, CI failures, and rebase conflicts on a recurring loop, or when asked to babysit/iterate on a PR
1