pr-re-review

PR Re-review

Static checks and a careful reader already cover what is visible in a diff. What neither covers is what this organization has learned: the agreement that says how this kind of change is made here, the finding raised on the last three pull requests in this file, the incident whose cause is one line above the change. A review that does not know those things re-litigates settled questions and misses the one that matters. This skill recalls them first, briefs the review with them, verifies every finding against the actual code before reporting it, and then offers the findings the team accepts back to memory so the next review starts where this one ended.

It is a second pass, and it says so in its name: it complements correctness-focused review and the project's own automated gates rather than replacing either. The merge decision is the human's.

Underneath, memory-search owns the search ladder and the relevance gate, graph-traversal owns relationship walking, and memory-capture owns the capture at the end — including its trust-tier gate, which is the reason this skill cannot store a lesson on its own say-so. All three ship with the gutt-pro plugin (this plugin depends on it); without them, follow the rules below and note the gap in one line. Repository and pull-request access comes from whatever tooling the session surfaces — a hosting-platform integration, or the local checkout and its CLI. Find it in your tool list; names and prefixes vary per install.

Hard rules (non-negotiable — read first)

1. The review is delivered to the human, not to the pull request. No approving, no requesting changes, no merging, no pushing, no branch or label edits, and no inline comments posted as a side effect of reviewing. Posting any of it is a separate act, done only when the user asks in this session and approves the exact text: it is outward-facing, other people are notified, and an apology does not retract it. Silence is not approval.
2. Every reported finding is verified at the source, and the verification is what makes it reportable. Before a finding reaches the output, open the file at the line and confirm the claim holds in the code as it now stands — including the rest of the diff, which routinely already handles what a lane flagged. A finding that survives is confirmed; one that cannot be checked is unverified and says why; one that does not survive is dropped, not softened. Findings from parallel lanes are the raw material for this step and are never the output of the skill.
3. A recalled standard is quoted and cited, or it is not a standard. An agreement, decision, or lesson used to justify a finding carries its source (id, date) and the words it actually says. Never generalize a remembered preference into a team rule, and never attribute a finding to memory that memory did not supply — an invented house rule is the one failure that discredits the whole review, because the author has no way to check it.
4. Severity is impact, not confidence, and the two are reported separately. must-fix means merging it causes harm — data loss, a security hole, a broken contract, a violated recorded agreement. should-fix means real cost, later. consider is taste, and taste is capped: say so and keep it short. Pre- existing conditions the PR merely touches are labeled pre-existing and never counted against it.
5. The lanes get the brief; the brief is not optional. Recall runs before any lane starts, and every lane prompt carries the recalled material verbatim along with the diff scope. A lane that has to guess the team's standards invents them, which rule 3 then has to catch one finding at a time.
6. Nothing is captured to memory without an explicit human signal. The capture at the end is an offer. A finding the user accepts may be proposed as a Lesson; memory-capture owns the classification and its tier gate, and a Lesson needs that human signal regardless of how obviously true the finding looks. Never capture a finding the author disputed, and never capture during the review — only after the outcome is known.
7. A capture lands in the engagement's group scope, explicitly and verifiably. Pass group_id naming that org group on the write, taken from a read that returned it — never guessed, never inferred from a write tool's name suffix, never left to the server to choose. Set last_n_episodes=0. Then read the episode back and confirm the group on the stored record is the one intended; report the group in the reply. Org writes cannot be undone from a normal session, which is why the check happens after the write rather than instead of it.
8. Org scope on reads, bare tool names, and no invented ids. Pass explicit group_ids naming the org group on reads — from session results or by asking. Call memory, repository, and issue tools by whatever names the tool list surfaces; probe with ToolSearch before concluding one is missing. Cite nodes by the readable ids a read returned; never hand-build one.