review-loop
starsforks
How to install review-loop?
minghinmatthewlam/agent-guards/review-loop
$npx -y skills add minghinmatthewlam/agent-guards --skill review-loopPost-implementation review/fix loop. Use host-appropriate review coverage on your implementation, fix issues, iterate until highly confident, then commit.
SKILL.md
| 1 | # Review Loop |
| 2 | |
| 3 | After implementation, harden it with structured `autoreview` coverage first. Fix, iterate, commit. |
| 4 | |
| 5 | Read-only analysis → use `audit-loop` instead. |
| 6 | Planning before implementation → use `plan-loop` instead. |
| 7 | |
| 8 | ## Prerequisites |
| 9 | |
| 10 | Read `~/dev/agent-guards/AGENTS.md` before applying fixes — the safety, workflow, and code conventions that govern all agent work. |
| 11 | |
| 12 | ## How It Works |
| 13 | |
| 14 | 1. **Review** your implementation per `references/review-protocol.md`. Use the `autoreview` skill as the default closeout reviewer for actual code diffs. Keep product context in the main session and pass only task-specific review notes when needed. Use fresh-context reviewer agents only for focused follow-up, ambiguous findings, or non-diff review. |
| 15 | 2. **Fix** issues found. Atomic commits (one logical fix per commit). After fixes that affect behavior, invoke `self-test` to re-verify on the real surface — don't trust code review alone. |
| 16 | 3. **Repeat** until confident. Follow the host-specific coverage rules every round. Run autonomously — do not pause for user input between rounds. |
| 17 | 4. **Commit and close** when confident. |
| 18 | |
| 19 | ## Gotchas |
| 20 | |
| 21 | - **Self-test after behavioral fixes is mandatory.** When a review round finds a behavioral bug and you fix it, use the Skill tool to invoke `self-test` to re-verify — don't trust the code review alone to confirm the fix works on the real surface. Skipping this is how "reviewed and fixed" changes still ship broken. |
| 22 | - In Codex-hosted runs, do not invoke Oracle, Claude, or other cross-model tooling just to satisfy review coverage. `autoreview --engine codex` is the expected path unless the human explicitly asks for an external second opinion or panel. |
| 23 | |
| 24 | ## Round Sizing |
| 25 | |
| 26 | - Default: |
| 27 | - R1: one `autoreview --engine codex` pass on the full diff. Web search stays enabled by default. |
| 28 | - R2+: rerun `autoreview` after accepted fixes. Focus any extra reviewer agents only on unresolved findings and changed code, not a fresh broad re-review. |
| 29 | - Optional panel: |
| 30 | - Use `--reviewers codex,claude` only when the user asks for Claude coverage, the change is high-risk, or the Codex-only result has low confidence. |
| 31 | |
| 32 | ## Confidence |
| 33 | |
| 34 | After each round, assess confidence 0-100 with top unknowns and what must be true to close: |
| 35 | - `<70`: another round, mandatory. |
| 36 | - `70-84`: one more focused round on residual risks. If still 70-84 after that, escalate to user with findings. |
| 37 | - `>=85`: eligible to close. Auto commit, push, and create PR. |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
