| name | code-review |
| description | Use when the user wants a code review instead of implementation. Prioritizes correctness bugs, behavioral regressions, missing tests, and risky assumptions. |
| version | 1.1.0 |
| author | Aixlarity (adapted from Hermes Agent requesting-code-review) |
| license | Apache-2.0 |
| metadata | {"aixlarity":{"tags":["code-review","quality","verification","pre-commit"],"related_skills":["tdd","systematic-debugging","security-audit"],"origin":"Hermes Agent requesting-code-review skill"}} |
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.
