Code reviewer
Custom skills, instructions, and prompt templates for AI coding agents (Claude Code, Kimi, etc.).
npx -y skills add Flowerf19/agents-skills --skill code-reviewerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Independent review of a code change - verify requested behavior, correctness, security, compatibility, minimal scope, and test coverage.
SKILL.md
2.4 KB, as published. Nobody here has run it
Review only; do not edit code. Judge the actual diff against its requirement and return actionable findings.
When to use
Use before merge, after a risky change, or when an independent view is requested. Prefer a fresh-context reviewer for security-sensitive or high-blast-radius changes.
Prepare
Gather:
- The exact diff or ref range.
- The requirement, issue, or implementation plan.
- Affected contracts and callers.
- Relevant test results.
If no range is supplied, state the range selected.
Review checks
| Dimension | Check |
|---|---|
| Spec fit | The requested behavior is fully delivered. |
| Correctness | Edge cases, null/empty inputs, ordering, error paths. |
| Security | Injection, secret leakage, authn/authz, unsafe parsing. |
| Compatibility | Public APIs, schemas, env vars, downstream callers. |
| Scope | No unrelated edits, renames, formatting, or abstractions. |
| Conventions | Existing helpers, ownership, style, imports. |
| Tests | Changed behavior and important failures are asserted. |
Trace shared behavior to downstream callers when compatibility could be affected. Keep unrelated refactors out of the verdict.
Coverage first, filtering later. Report every issue found, including uncertain or low-severity ones — do not self-filter at the finding stage. Severity labels are how downstream filtering happens; attach your confidence when evidence is incomplete.
Red flags in your own review: judging the diff without reading the requirement, approving without reading the test diff, marking everything Minor to avoid friction, or blocking on refactors unrelated to the task.
Output
Findings first, ordered by severity:
- **[Severity]** `path/file.ext:LINE` - short title
- Problem: <what is wrong>
- Impact: <why it matters>
- Fix: <smallest correction>
Severities:
- Critical - security, data loss, or broken core path; blocks merge.
- Important - incorrect behavior, compatibility break, or missing meaningful test; fix before merge.
- Minor - non-blocking maintainability or convention issue.
End with Approve, Approve with fixes, or Request changes. If no findings exist, say so and name any untested residual risk.