review-bug-fixer
Review Bug Fixer
Fix valid code review findings from arbitrary review markdown files against the current branch.
Workflow
-
Collect review files — Read all review files the user provides (e.g.,
review1.md,review2.md,review3.md). Accept any number of files in any format (structured or free-form). -
Build a unified issue list — Extract every distinct finding across all files. Deduplicate: if multiple files flag the same issue (same file + same concern), merge them into one entry. Preserve the strongest/clearest description.
-
Triage each finding — Classify every finding into one of:
- Fix — Valid bug, logic error, security issue, or correctness problem. Apply the fix.
- Skip — Ignore if any of these apply:
- Nit or style-only (naming preferences, formatting, comment wording)
- Not actually valid (misunderstanding of the code, already handled, false positive)
- Overly defensive (adds complexity for scenarios that realistically won't occur — e.g., redundant null checks on values guaranteed by the framework, error handling for impossible states, excessive input validation on internal-only code paths)
When in doubt, lean toward skipping. The goal is to fix real bugs, not gold-plate the code.
-
Fix valid issues — For each "Fix" finding:
- Read the relevant source file if not already read
- Apply the minimal change that addresses the issue
- Do not refactor surrounding code or add unrelated improvements
-
Report summary — After all fixes, output a brief summary:
## Review fixes applied ### Fixed - <file:line> — <one-line description> ### Skipped (not valid / nit / overly defensive) - <one-line description> — <reason skipped>
Guidelines
- Never create new files unless a finding explicitly requires it.
- Keep fixes minimal and focused — one concern per edit.
- If a finding is ambiguous or could go either way, skip it and mention it in the summary so the user can decide.
- If two findings conflict, skip both and flag in the summary.
- Preserve existing code style (indentation, naming conventions, patterns).
More from ilamanov/skills
spec-builder
Transform vague product or feature ideas into concrete, detailed specification documents through an interactive interview process. Use when the user wants to flesh out an idea, create a spec, write requirements, plan a product/feature/prototype, or go from "I have this idea..." to a concrete document. Works for software products, physical products, services, or any concept that needs specification.
23pr
Commit changes and create or update a pull request following project standards. Use when the user wants to commit work, create a PR, update an existing PR, or use the /pr command.
14reimplement-branch
Reimplement the current branch on a new branch with a clean, narrative-quality git commit history. Use when the user wants to clean up messy commits, create a tutorial-style commit history, or prepare a branch for review with logical, self-contained commits. Triggers on requests like "clean up my commits", "reimplement this branch", "create a clean history", or "make my commits reviewable".
12deslop
Remove AI-generated code slop from the current branch. Use when the user says "deslop" or asks to clean up AI slop, remove AI code patterns, or clean the branch before committing.
9compile-conversation-into-doc
Turn long, messy AI chat conversations into clear, durable, and easily scannable reference documents that humans can reliably return to weeks or months later.
9incremental-plan
Break a product or feature spec into a sequence of small, independently testable implementation steps. Use when the user has a spec document and wants to implement it incrementally rather than all at once — building and verifying one piece at a time before moving on. Triggers on requests like "break this spec into steps", "create an incremental plan", "split this into parts I can test", "how should I implement this step by step", "create a build plan", or when a user has a spec and wants a phased implementation approach.
6