voidful Code Review
Core Principle
No agent should verify its own work. A code review uses a fresh perspective to find what the author missed.
When to Use
- After implementing a feature or bug fix, before committing.
- When user says "review", "check", "look at", or "what's wrong with".
- After completing a task with 2+ file edits.
Review Priorities (in order)
- Correctness bugs — Does the code do what it claims to do?
- Behavioral regressions — Does it break existing functionality?
- Missing tests — Are there untested code paths?
- Risky assumptions — Are there hardcoded values, unchecked errors, or race conditions?
- Security — Prompt injection, path traversal, credential exposure.
Review Process
- Read the diff or file(s) under review.
- Check if tests exist for the changed code. If not, flag it.
- Look for edge cases the author likely did not consider.
- Keep the summary short after the findings. Focus on actionable items.
Output Format
For each finding:
[SEVERITY] Description
File: path/to/file.rs:line
Why: explanation of the risk
Fix: suggested change (if obvious)
Severity levels: CRITICAL, WARNING, INFO.
What NOT to Do
- Do not nitpick style issues that a linter should catch.
- Do not rewrite the code. This is a review, not an implementation.
- Do not praise code just to be polite. Be direct and useful.