reviewing-code — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited reviewing-code (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.
Review code changes systematically using priority-based rules. Focus on what automated linters miss — performance, architecture, test coverage, and security patterns.
| Category | What to look for |
|---|---|
| N+1 queries | Database/API call inside a loop; resolver without batching |
| Security | Missing auth check on endpoint; fail-open permission pattern; SQL injection; XSS |
| Data loss | Missing error handling on write operations; no transaction for multi-step mutations |
| Memory leaks | Uncleaned subscriptions, timers, or event listeners in effects |
| Category | What to look for |
|---|---|
| Performance | O(n²) when O(n) is possible; expensive computation in render path; missing memoization for derived data; large bundle imports |
| Error handling | Missing try/catch on async operations; swallowed errors; missing error boundaries |
| Test coverage | New business logic without tests; untested error paths; missing edge cases |
| Null safety | Accessing nested properties without null checks; missing optional chaining |
| React hooks | Missing dependencies in useEffect; missing cleanup functions; hooks inside conditions |
| Category | What to look for |
|---|---|
| Naming | Unclear variable/function names; inconsistent naming patterns |
| Code organization | Logic in wrong layer (UI doing business logic); duplicated code |
| Types | Missing type annotations on public APIs; any types |
| Clean code | Magic numbers; deeply nested conditionals; functions doing too many things |
These are rarely caught by human reviewers. The skill must catch them:
DO: Provide full verbal explanations
"This calls the user service inside a loop. With 50 users, that's
51 database calls instead of 2. Batch the IDs and make a single
query with a WHERE IN clause."DON'T: Leave terse comments without context
"N+1 query"For each issue:
### [P0] Short Description
**File:** path/to/file.ts:42
**Issue:** [Full explanation of the problem and its impact]
**Fix:**
// Before
[problematic code]
// After
[fixed code]When reviewing code in-place, use these markers:
// FIXME(review): [P0] N+1 query — will cause performance degradation at scale
// TODO(review): [P1] Add error handling for network failure case
// NIT(review): Consider renaming for clarityPresent the summary with issue counts by severity, then ask the user what to do next:
| Thought | Reality |
|---|---|
| "This is too simple to review" | Simple changes break things. Review. |
| "Tests pass so it's fine" | Tests can't catch what they don't cover. Review. |
| "It's just a refactor" | Refactors introduce subtle bugs. Review. |
| "The linter will catch it" | Linters miss logic, performance, and architecture. Review. |
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.