code-review — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited code-review (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
This skill provides a structured approach to code review: what to check, how to communicate feedback, and how to receive it. Activate it when reviewing a PR, preparing your own code for review, or establishing review norms for a team.
#### Correctness
#### Design
#### Readability
#### Tests
#### Security
#### Dependencies and supply chain
#### Performance
Be specific: point to the exact line and explain the concern.
Label every comment with Conventional Comments: <label> [decorations]: <subject>, then optional discussion.
praise, nitpick, suggestion, issue, todo, question, thought, chore, note(blocking), (non-blocking), (if-minor) — e.g. issue (blocking): … for a must-fix, nitpick (non-blocking): … for tasteBe constructive: suggest an alternative, don't just say "this is wrong." Pair each issue with a concrete fix or a question.
Praise sincerely with praise: when something is genuinely good — one specific line, not filler.
Respond fast: acknowledge a review request within one business day, even if the full review comes later. Slow reviews push authors toward bigger, riskier PRs.
AI-written code gets the same bar as human code: verify that every API, flag, and config key it uses actually exists in the pinned version.
Google's engineering practices: about 100 lines is usually a reasonable change, 1000 lines is usually too large, and spread matters — 200 lines in one file can be fine while the same 200 across 50 files is not. Split refactors from behavior changes, and stack dependent PRs instead of growing one.
Large PRs get shallow reviews. Smaller PRs get better feedback faster.
issue (blocking): This function panics on empty input (line 42). The
`unwrap()` on `items.first()` will crash if the slice is empty. Consider
returning `Option<T>` or checking `items.is_empty()` first.# Bad
This is wrong.
Why did you do it this way?
# Good
suggestion (non-blocking): Using a HashMap here would reduce lookup from
O(n) to O(1). Since this runs on every request, it may be worth the memory.## What
Brief description of the change.
## Why
The problem this solves or the feature this adds.
## How
Key implementation decisions and trade-offs.
## Testing
How you verified this works.~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.