♠ Previously.
My dual-review skill runs two independent LLM reviewers over a commit / diff / PR, validates every finding against the code, and hands back one action plan — Blockers, Important, Suggestions.
Recently I added a flag argument that closes the loop:
argument-hint: "[branch|staged|all] [--pr NUMBER] [--post]"
+argument-hint: "[branch|staged|all] [--pr NUMBER] [--post] [--address]"
- `--post`: post final action plan to target pull request after showing it; never post otherwise
+- `--address`: after showing (and, if requested, posting) the action plan, fix Blockers and Important findings directly in the reviewed tree; never fix Suggestions without explicit confirmation
+## 7. Address Findings (only with `--address`)
+
+Skip this section entirely unless `--address` was requested.
+
+1. Work in the same tree that was reviewed (existing worktree or user's checkout for `staged`/` all`); never create a second copy of the changes.
+2. Address every Blocker and every Important finding. For Suggestions, ask the user which (if any) to apply; default to none.
+3. For each finding: re-read the exact `file:line` locations, apply the `Fix:` recommendation, and fix every sibling location listed under that finding, not just the first instance.
+4. If a finding is ambiguous, requires a design decision, or the recommended fix turns out to be wrong once you're in the code, stop and ask the user instead of guessing.
+5. After edits, rerun any locally available checks that cover the change (tests, linters, type-checks) before treating a finding as resolved.
+6. Stage only the files touched while addressing findings. Commit with a message describing which findings were fixed (e.g. `address dual-review findings`), listing them briefly in the body.
+7. If scope was `branch`/`--pr`, push to the branch. If the action plan was posted (`--post`), leave a short follow-up comment noting the findings were addressed and pushed; do not repost the full plan.
+8. Report: which findings were fixed, which were skipped and why, and which need user input.
The important line is the second one: Suggestions never get auto-applied, only Blockers and Important.
/dual-review --post --address
now reviews, posts the plan, fixes what’s fixable, and pushes.
Why two review(er)s instead of one? Because LLMs are non-deterministic.
Why not more than two review(er)s then? Tokens ($$$) and time. It’s a balance.
🤖 *Drafted with *
/bloggify
.— § —
Reply via [email](mailto:serendipity@perrotta.dev?subject=Reply to: dual-review: address review findings automatically)