simplify-code-46f120 — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited simplify-code-46f120 (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 your recent code changes with three focused reviewers running in parallel, aggregate their findings, and apply the fixes worth applying.
Core principle: Three narrow reviewers beat one broad reviewer. Each one deeply searches the codebase for a single class of problem — reuse, quality, efficiency — without diluting its attention across all three. They run concurrently, so you pay the latency of one review, not three.
Trigger this skill when the user says any of:
Optional modifiers the user may add — honor them:
(or weight the aggregation toward it). Recognized focuses: reuse, quality, efficiency.
three reviewers, present findings, apply NOTHING. Ask before applying.
src/foo.py" → narrow the diff source accordingly (see Phase 1).
Do NOT auto-run this after every edit. It costs three subagents' worth of tokens — invoke it only when the user explicitly asks.
Capture the diff to review. Pick the source by what the user asked for, in this default order:
# 1. Default: uncommitted working-tree changes (tracked files)
git diff
# 2. If that's empty, include staged changes
git diff HEAD
# 3. Scoped variants the user may request:
git diff --staged # "staged changes"
git diff HEAD~1 # "the last commit"
git diff main...HEAD # "this branch" / "my PR"
git diff -- src/foo.py # specific file(s)If git diff and git diff HEAD are both empty and there's no git repo or no changes, fall back to the files the user explicitly named or that were recently created/edited in this session. If you genuinely can't find any changed code, say so and stop — there's nothing to simplify.
Capture the full diff text. Note its size: if it's very large (say >2000 changed lines), warn the user that three subagents each carrying the full diff will be token-heavy, and offer to scope it down (per-directory, per-commit) before proceeding.
Use delegate_task batch mode — pass all three tasks in one tasks array so they run concurrently. Three is the right fan-out for this pattern; it's well within the delegation.max_concurrent_children budget on any default install.
Give every reviewer the complete diff (not fragments — cross-file issues hide in the gaps) plus the absolute repo path so they can search the wider codebase. Each reviewer gets terminal, file, and search toolsets (so they can git, read_file, and search_files/grep).
Tell each reviewer to:
file:line → problem → suggested fix.high / medium / low confidence.the code.
Pass these three goals (drop any the user's focus excludes):
Reviewer 1 — Code Reuse
Review this diff for code that duplicates functionality already in the codebase. Search utility modules, shared helpers, and adjacent files (use search_files / grep) for existing functions, constants, or patterns the new code could call instead of reimplementing. Flag: new functions that duplicate existing ones; hand-rolled logic that an existing utility already does (manual string/path manipulation, custom env checks, ad-hoc type guards, re-implemented parsing). For each, name the existing thing to use and where it lives.
Reviewer 2 — Code Quality
Review this diff for quality problems. Look for: redundant state (values that duplicate or could be derived from existing state; caches that don't need to exist); parameter sprawl (new params bolted on where the function should have been restructured); copy-paste-with-variation (near-duplicate blocks that should share an abstraction); leaky abstractions (exposing internals, breaking an existing encapsulation boundary); stringly-typed code (raw strings where a constant/enum/registry already exists — check the canonical registries before flagging). For each, give the concrete refactor.
Reviewer 3 — Efficiency
Review this diff for efficiency problems. Look for: unnecessary work (redundant computation, repeated file reads, duplicate API calls, N+1 access patterns); missed concurrency (independent ops run sequentially); hot-path bloat (heavy/blocking work on startup or per-request paths); TOCTOU anti-patterns (existence pre-checks before an op instead of doing the op and handling the error); memory issues (unbounded growth, missing cleanup, listener/handle leaks); overly broad reads (loading whole files when a slice would do). For each, give the concrete fix and why it's faster or lighter.
Wait for all three to return (batch mode returns them together).
argue with a reviewer, just drop weak or wrong suggestions silently.
util X"; Reviewer 3: "X is slow, inline it"). Default resolution order: correctness > the user's stated focus > readability/reuse > micro-perf. Don't apply a perf "fix" that hurts clarity unless the path is genuinely hot. When two suggestions are mutually exclusive and both defensible, pick the one that touches less code and note the alternative.
patch / write_file — unlessthe user asked for a dry run, in which case present the list and ask first.
the touched files (not the full suite), and re-run any linter/type check the repo uses. If a fix breaks a test, revert that one fix and report it.
reviewer category, plus any findings you deliberately skipped and why.
conflicting suggestions to reconcile, not better coverage. Three categories cover the space.
defeats the design — cross-file duplication and N+1s only show up with the full picture.
the existing utility ("there's probably a helper for this") is noise. Require file:line evidence; drop findings that lack it.
license to refactor the whole module. Keep edits scoped to what the diff touched plus the minimal surrounding change a fix requires.
HERMES.md or a linter config, fold those rules into the reviewer prompts so suggestions match house style instead of fighting it.
delegating — three subagents each carrying a 5000-line diff is expensive and may truncate.
If your install has the subagent-driven-development skill (optional), it covers the complementary case: parallel review during implementation, per task. This skill is the standalone after-the-fact cleanup pass. Use requesting-code-review for the pre-commit security/quality gate.
Before applying this skill:
While working:
After completing:
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.