review-it

Review it

1. Pin

Run the affected checks, commit everything including new files, fetch the target branch, and pin <merge-base with origin/<target>>..HEAD. HEAD stays fixed while reviewers run.

Merging or rebasing the target branch into a reviewed branch changes no reviewed code, so it needs no new review when the PR's own changes are unchanged; land-it checks that by comparing trees. Review again only when the PR's own changes moved.

Write down the intent and acceptance criteria, chat-only ones included, and the model families that wrote the change, delegated workers included. Decide write-pr's Visible: value: yes when the change alters a screen users see or use. For yes, capture write-pr's screenshots from the pinned HEAD now, so the reviewers judge them. Record any video once, after the fixes, on the head that merges.

2. Grade

• skip: only docs, comments or copy; no code that runs and no agent

instructions.

• high: you can name the concrete hazard: the diff changes how auth,

permissions, payments, secrets, migrations or stored data behave, or a public contract or stored format in a way a revert cannot undo. A file in one of those areas whose behaviour stays the same is not a hazard.

• standard: every other change, however many files or subsystems it touches.

standard is the grade unless you can name a high hazard. A grade the user gives is a floor. skip goes straight to the receipt. The grade sets reviewer effort; write-pr's Door line, not the grade, decides whether land-it merges without the user. A high hazard a revert cannot undo makes the PR Door: one-way.

3. Review

Run interrogate once on the pinned range: two reviewers in parallel from the interrogate reviewers line of pstack-models.md, resolved with t3-capacity, starting with the seat whose lead model did not write the change, each seat falling through its tiers when a model is out of capacity. Reviewers run at high for standard and xhigh for high. Every brief carries the intent and acceptance criteria, the pinned range, the absolute path of the review brief, the worktree, and the paths of any spec, issue and repo instruction files, and your Visible: value; a reviewer who finds that the change alters a screen users see or use when it says no reports it as a finding. For yes, every brief also carries the demo's paths and the prototype the user approved, when there is one, and asks the reviewer to judge the demo as the user will, with the installed design skills such as frontend-design and emil-design-eng: whether it matches the prototype, and any stray, missing or misaligned element, uneven spacing, text users do not need, or a state that looks broken. The Act On findings are the findings; a Consider finding you do not apply counts as rejected, with its reason, so the receipt shows every disagreement. Dismissed items are the reviewers' own rejections and count nowhere.

Staff every reviewer through delegate_task in runtime mode full-access with the read-only brief: a headless run has nobody to approve it. When every model on the line is out of capacity, report a blocker. Where delegate_task is unavailable, as in a subagent (parent_not_active), hand the pinned range back to the parent as a blocker. After staffing, end the turn; the completion notifications wake you.

A review counts once it returns a substantive verdict on the pinned HEAD; restaff refusals, quota errors and empty results. Watch every Grok seat for a stalled run as ~/.agents/skills/poteto-mode/references/t3-execution.md describes: a stalled seat's final verdict counts as its review. A finding that names a concrete high hazard raises the grade to high in the receipt; it adds no review round. A finding that names a hazard a revert cannot undo sets Door: one-way unless a fix removes the hazard.

4. Fix

Verify and deduplicate the findings, then apply the valid in-scope ones, structural simplifications included, in one batch. Decide design questions the findings raise yourself and record the choice in the PR's What and why. A fix that needs a new design or roughly doubles the diff becomes a follow-up issue, declined with the reason follow-up #<issue>, unless it is a correctness or security bug in this diff. Rerun the affected checks and commit. When a fix changes a screen users see, retake only the screenshots it changed and check them against the findings yourself. Then record write-pr's video, when it needs one, from the final HEAD: the user OKs the demo of the head that merges.

Check every fix yourself against its finding and commit it. Run a confirmation review only when a fix changed behaviour beyond what its finding named: one new reviewer at high from the interrogate reviewers line, preferably one that did not write the fixes, reads only the fix range (the last reviewed head to the new HEAD) with the prior findings. Apply, check and commit its valid findings. After that one confirmation, the correctness and security findings still unfixed count as open and go to the user. A PR gets one full review; confirmations only read fixes.

5. Receipt

Return this line for write-pr's Review section, plus any blocker and its next step. land-it parses it, so keep its exact shape. rejected counts findings the reviewers raised and the authors declined; open counts findings handed to the user, blockers and seats that never returned a verdict; reviewed names the base branch and the head the last round saw, or the head after the fixes you checked against their findings when no confirmation ran:

**Review.** <skip | standard | high> by <models>; <n> fixed, <n> rejected, <n> open; reviewed <short SHA> on <base branch>

Under it, write one line per rejected finding:

- Declined: <finding> (raised by <model>): <specific reason>

Name every model that raised the finding. A finding two reviewers raised cannot be declined: fix it, or it stays open. When it is not a correctness or security bug, a follow-up issue may take it, with the reason follow-up #<issue>.