A round is one sweep of review passes, then the fixes they earn. The ledger is every finding from every round with its disposition, kept in a file so it survives a restart. Every pass and every fix runs in a sub-agent.

Quick mode

A quick polish, asked for by name or with --quick, trades depth for speed. It runs the steps below with these overrides:

Step 1: when no spec turns up, proceed without one. Browser QA is never live.
Step 2: the plan is /code-review at medium effort, plus /mattpocock-skills:code-review when there is a spec.
Step 5: go straight to step 6.
Step 6: dispatch /tidy alone, then /code-review low --fix over the fix and tidy commits together, so it hunts regressions in the round's fixes.
Step 7: the opening lines say this was a quick polish and name what it skipped.

1. Establish the scope

The fixed point is the one the user named, else the current branch's merge-base with its base branch. Commit any uncommitted changes per /commit first, so every pass reads the same tree.

Find the spec once: the one already in this session, issue references in the commit messages, the open PR, or a spec file matching the branch under docs/, specs/, or .scratch/. If none turns up, ask the user once. The spec, or its confirmed absence, goes into every brief.

Browser QA is live when the app is browser-driven and the change under review touches something a user sees. When it is, dispatch a sub-agent to set up the fixtures every round's QA reuses: the test data the affected flows need, built with the project's seeds or the run skill. It returns each fixture with how to reach it (ID, URL, or sign-in), and where each flow's effects land outside the app, such as a CRM record or an analytics event. Once the fixtures are saved, it tears down any browser session or app process it started.