audit — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited audit (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.
Audits one Go package for real issues. Separates detection from evaluation to filter out false positives. Presents only findings worth acting on. No edits without explicit approval.
If user provided a path argument (e.g. /audit ./internal/init/), use that package. If no argument, run git diff --name-only HEAD~1 HEAD to find which packages changed — pick the one with most changes. If no diff and no argument, ask the user.
Scope is ALWAYS one Go package (one directory). Never audit multiple packages at once.
Launch three Agent tool calls in a single message. Each agent MUST:
.go files in the package completelyBefore reporting any finding:
Do NOT report:
Search the full codebase for existing helpers that could replace code in this package. Flag duplicated logic within the package. Flag hand-rolled operations where a stdlib or project utility exists.
Review for inconsistent patterns within the package, copy-paste with variation, exported symbols that should be internal, stale docstrings that don't match implementation, redundant state.
Review for redundant computations, hardcoded values that duplicate a constant defined elsewhere, missing error context (bare err returns), TOCTOU patterns, unsafe concurrent access to shared state.
Collect all raw findings from Step 2. For EACH finding, answer these four questions:
1. IS IT REAL? Read the full function and surrounding code. Check for comments explaining the pattern. Check if the pattern appears intentional in context. If you cannot rule out that it's intentional, discard it.
2. WHAT BREAKS IF WE DON'T FIX IT? Describe a concrete scenario: "if someone does X, this will silently Y because Z." If no concrete scenario exists, it's cosmetic — move to appendix.
3. AUTHOR TEST: If the person who wrote this code saw your finding, would they say "good catch" or "you don't understand the context"? If you're not confident they'd say "good catch", move to appendix.
4. BLAST RADIUS: How many files does the fix touch? If >3 files, flag as "larger refactor, needs its own round."
After evaluation, categorize into two buckets:
Must satisfy ALL of:
Order by impact (what breaks worst comes first).
Everything else. Summarize in one line: "There are also N minor findings (cosmetic, style, minor inconsistencies). Say 'show appendix' to see them."
For each "fix now" finding, show:
Then say: "Fix these? (yes / pick numbers / skip)"
Do NOT proceed to any edits without explicit user instruction.
For each approved finding, in sequence:
go build ./... — must compilego test ./<package>/... -count=1 -short — must passAfter all approved fixes are done, run go test ./... -count=1 -short (full suite).
Summarize: what was fixed, what was skipped, what failed.
If there are appendix items, remind: "There are N more minor findings from the appendix. Say '/audit' again or 'show appendix' to continue."
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.