A general-purpose output auditing skill for Claude, Codex, Gemini CLI, and other agents
SaferSkills independently audited harden (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.
MANDATORY: Re-read this entire file before every audit pass. Do not rely on earlier readings within the same conversation. Context window drift causes skipped steps.
Ensures substantial deliverables are structurally sound, internally consistent, and aligned with domain best practices before delivery. Replaces ad hoc quality checks with a repeatable methodology.
before auditing (not just internal assumptions)
structure (do paths/references/formatting work?)
with specific locations
Search for current best practices specific to the deliverable's domain.
Scope guidance:
skill docs)
NIH guidelines, successful examples, common reviewer complaints)
authoritative document for this domain (official guide, spec, standard), fetch and read it — do not rely on search snippets. Snippets capture ~5% of a document's content and miss testing, edge cases, and patterns. Limit to the first ~5000 tokens if the source is very long; prioritize sections on requirements, validation, and common mistakes.
reading list
If web search is unavailable: State this limitation explicitly. Proceed using training knowledge but flag that the audit lacks external validation.
Run TWO distinct passes within this step. Both are mandatory.
Pass A — Thematic audit (ideas level):
Pass B — Structural audit (artifact level):
Pass C — Regression check (only when re-hardening a modified deliverable):
Trigger detection: Apply Pass C when the deliverable was previously completed or delivered and is now being revised — indicated by the user referencing a prior version, requesting modifications to existing work, or re-submitting after changes. Examples: "update the roadmap I wrote earlier", "fix the issues you found", or any edit to an artifact that was previously declared done.
Severity classification for every issue found:
misunderstanding. Must fix.
confusion, or wastes resources (tokens, time). Must fix.
Required output structure:
proves the audit actually examined these areas rather than skipping them.
and specific location (line number, section name, or quote).
remediation for each.
Execute all 🔴 and 🟡 fixes. Do not cherry-pick. Do not defer significant issues. Fix 🟢 issues if they're adjacent to other changes.
After fixes, run a mechanical verification:
Evaluate what this pass found:
Limits: 2 passes is typical. 3 is maximum. If still finding critical issues after 3 passes, flag to the user that the deliverable may need fundamental restructuring rather than incremental fixes.
Re-hardening trigger: When external standards change (new Anthropic docs, updated NIH guidelines, framework version bumps), previously hardened deliverables should be re-audited against the new standards. The user triggers this manually; the skill treats it as a fresh hardening with Pass C enabled.
When auditing, identify the relevant quality criteria for the deliverable type. For domains not listed below, generate criteria by asking: "What would an expert reviewer check before approving this?"
conventional but not required), description (third person, non-empty, all triggers included; Anthropic Help Center states <=200 chars, ecosystem convention <=1024 chars — test auto-invocation if exceeding 200)
specific platform), declare them in the compatibility frontmatter field AND mention the primary dependency in the description
compare its answer against intended triggers. Check for under-triggering (missing expected phrases) and over-triggering (matching unrelated queries)
steps appear early in the document
approach (feasible, risks mitigated), alignment (budget matches scope)
correspondence with its detailed execution section. No step in one without a match in the other.
Flag: config created before its target exists, files referenced before creation, tools invoked before dependencies are available.
actually exist. Verify against the known environment — not assumptions or recall. Flag speculative or hallucinated commands.
(command hooks = grep/regex, prompt hooks = LLM yes/no, agent hooks = multi-turn). Flag rules requiring capabilities beyond their type.
expected output, a file/state existence check, or an observable result. "Verify it works" and "run tests" without specifics are insufficient — a literal executor must be able to confirm success without follow-up.
"Check that the file exists" is falsifiable. "Review the output" is not.
Performative skepticism: Adding self-critical commentary ("you might want to strengthen this") without running the actual audit process. Sounds rigorous, catches nothing structural.
Thematic-only auditing: Checking that ideas are sound while ignoring paths, names, formatting, and consistency. How 14 issues survived a "validated" deliverable in prior experience.
Structural-only auditing: The inverse — checking paths and formatting while missing that the ideas are wrong or incomplete.
Severity inflation: Marking everything 🔴 to appear thorough. Reserve critical for actual failure modes.
Audit without research: Skipping Step 1 and auditing against internal assumptions rather than external standards. The research step imports criteria that wouldn't be generated otherwise.
Snippet-depth research: Finding the canonical source but reading only search result excerpts instead of fetching the full document. Captures technical requirements but misses testing methodology, edge cases, and behavioral patterns. How 4 relevant quality criteria were missed despite the source appearing twice in search results.
Skipping "what passes": Only reporting failures without confirming what was reviewed and found correct. Hides gaps in audit coverage.
Static-only plan auditing: Checking that references resolve and formatting is correct while treating a sequential plan as a static document. Plans are executable — each step has preconditions. Auditing a plan without simulating execution order misses ordering violations, summary↔detail drift, and nonexistent tool references. How 7 issues (4 moderate) survived 4 audit passes on an implementation plan.
Verification-free planning: Approving an implementation plan where tasks lack concrete verification methods. Every task produces a result; every result can be checked. Plans without per-task verification shift the burden to the executor to invent checks — which means they often don't.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.