review-implementation — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited review-implementation (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.
The findings engine the review/audit skills compose: it produces findings and a decision table, and stops — never refactors or edits code. It owns the review axes (Phase 1) and the classification rubric (Phase 2) that review-change, audit-pr, and product-audit reference instead of restating.
review-change (the user-facing review entry) as its engine; theaudit skills reference its rubric.
platform-adaptive orchestration review-change adds.
Default target is the current change (branch diff vs. the default branch); accept an explicit path/glob to widen or narrow it. State the scope at the top of the report so the reader knows what was and wasn't reviewed.
Per the agent guide's Workflow conventions + documentation map, then read what THIS skill needs: the architecture/layering rules, the testing philosophy, and any runtime/platform, security, money, i18n/SEO/a11y and bundle rules. Pull the project's specific risk axes from its guardrail skills where present (architecture-pattern, runtime/platform, domain-rules). The axis list below is the default; the project's docs refine it.
Scan the scope and record findings across these axes. Fix nothing.
| # | Axis | Looks for |
|---|---|---|
| 1 | Bug / correctness | Logic errors, wrong edge-case handling, races, unhandled rejections, imprecise numeric handling |
| 2 | Architecture violation | Broken dependency direction, business logic in the wrong layer, abstraction bypass, cross-layer shortcut (per the architecture doc) |
| 3 | Overengineering / premature optimization | Unnecessary abstractions, single-caller indirection, speculative generality, micro-opt without a measured bottleneck |
| 4 | Removable / dead code | Unused exports, unreachable branches, commented-out blocks, obsolete files — see exception below |
| 5 | Security / cybersecurity | Secrets in code, injection, missing authz, unsafe deserialization, PII exposure, weak crypto, SSRF, over-broad CORS, leaking errors |
| 6 | Platform / runtime incompatibility | APIs unavailable on the target runtime, unsupported in-memory state assumptions, runtime-incompatible deps, blocking external calls in the request path |
| 7 | Bundle-size risk | Heavy/duplicate deps, accidental large imports, non-tree-shakeable patterns |
| 8 | Tests — failing/weak | Flaky/over-mocked/snapshot-heavy tests, tests asserting nothing meaningful |
| 9 | Tests — missing | Uncovered branches, new use-cases/adapters without tests, SPEC dev-scenario failure modes not exercised |
| 10 | Project-rule violations | Whatever the project's docs mandate (e.g. domain value-object rules, no hardcoded UI strings, don't hide user-facing limitations, naming conventions) |
Do not flag code as removable if it is intentionally staged for an in-progress or planned feature. Before reporting axis 4, cross-check the roadmap, feature SPECs/TASKS.md, and known-issues.md: if the code is wired into a planned phase or another feature, classify it intentional / in-progress, not dead. When unsure, mark it verify and ask — never assert "dead" on a guess.
Each finding: a stable id (F-1, F-2, …), file:line, axis, a one-line description, and the evidence (the code/why it qualifies). No remedy code yet.
Turn findings into a decision table. Classify each into exactly one of:
trigger), not inline work.
where future readers will see it.
For every finding, give the reasoning columns. Example (generic — your findings, your domains):
| Finding | Axis | Sev | Class | WHY | Implementation risk | Long-term impact | Premature-opt? | Route |
|---|---|---|---|---|---|---|---|---|
| API token committed in a config file | security | high | fix-now | Credential exposure | Low (move to secret store) | Incident risk | no | plan-fix |
| New export endpoint has no tests | tests | med | fix-now | Untested failure path | Low | Regression risk | no | fold into phase |
| Helper duplicated across 2 modules | maintainability | low | intentional-tradeoff | Coupling the 2 callers is worse | — | Near-zero divergence | no | note in decisions.md |
| Single-caller wrapper around a stdlib call | overengineering | low | ignore | Indirection with no payoff | — | Negligible | no | note rationale |
blocker. med: degraded behavior, a real untested path, or notable debt. low: taste, cosmetics, or micro-optimization without a measured need.
plan-fix → execute-phase --fix, or fold into thecurrent feature phase if part of unmerged work.
triage-issue owns it thereafter. Do not implement inline.
decisions.md, or anissue documenting the choice) so it isn't re-flagged.
cite file:line, mark uncertainties verify.
the platform's applicable companion reviews (/code-review, /security-review, /verify, design/a11y/brand…). audit-pr and product-audit reuse this rubric.
fix-now/postpone outcomes hand off to plan-fix / triage-issue.every finding classified with reasoning, each routed — and no code changed.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.