agentleFS
Evan-DaruwallaEvan-Daruwalla/claude-skill-suite/audit/SKILL.md

audit

Skill0 starsChanged 45 days agoMITView on GitHub

Cold whole-project audit of code AND docs by a fresh agent under a coverage manifest, plus the cross-check neither does alone (docs vs disk, code vs intent). Use when: "audit", "full audit", "audit everything", "what could break". Findings only.

194 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use delight, teach-impeccable and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • HK-hubSkill

    delight

    Add moments of joy, personality, and unexpected touches that make interfaces memorable and enjoyable to use. Elevates functional to delightful. Use when the user asks to add polish, personality, animations, micro-interactions, delight, or make an interface feel fun or memorable.

    Also in 32 projects that use this

  • HK-hubSkill

    teach-impeccable

    One-time setup that gathers design context for your project and saves it to your AI config file. Run once to establish persistent design guidelines.

    Also in 19 projects that use this

  • zwy123zwySkill

    normalize

    将用户随意输入的提示词规范化为结构清晰、便于大模型执行的标准化提示词。适用于需要整理、统一提示词格式时调用。

    Also in 19 projects that use this

  • SkillPilotCHSkill

    level-up

    Eine Automatisierung pro Woche finden, scopen, shippen. Output landet als proposed-Eintrag in cadence.md mit konkreten Implementations-Schritten.

    Also in 12 projects that use this

  • ww-w-aiSkill

    pm-discovery

    PM Agent Team - Automated product discovery, strategy, and PRD generation. Runs PM analysis workflow to produce comprehensive PRD before PDCA Plan phase.

    Also in 3 projects that use this

  • +7 more from HK-hub

The file

We split this skill into the rules it gives an agent

11 rules. 0 are common, 6 are distinctive, and 5 are very specific to this project.

  • 0

    Common

    Most of the 176 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Scope is an argument, not a separate skill: Default is the whole project.

    line 25
  2. Very specific:

    Use audit when the user says "audit" with no qualifier.

    line 30
  3. Distinctive:

    Read each reference file as you reach its step.

    line 56
  4. Distinctive:

    5. Verify before reporting: Every crit and high is reproduced by the session model itself, with the command and its real output pasted.

    line 107
  5. Distinctive:

    The findings pass changes NOTHING: No drive-by fixes, no "improved while I was there".

    line 127
  6. Very specific:

    Never invent a number, measurement, or timestamp: Run date before writing any timestamp.

    line 133
  7. Distinctive:

    Every fix is surgical or it is honestly labelled large: Prefer one guard at the shared chokepoint over N guards at call sites — smaller …

    line 135
  8. Distinctive:

    Keep tokens low per unit of coverage: sample large files, prefer grep and queries over full reads, and never paste long code excerpts into …

    line 140
  9. Very specific:

    Every .md file this skill creates or writes to gets ASCII characters only (bytes 0x00-0x7F) in the text you add.

    line 145
  10. Very specific:

    Check before saving. In a git repo, git diff -U0 -- <file> | grep -v '^+++' | grep '^+' | grep -nP '[^\x00-\x7F]' must print nothing.

    line 153
  11. Distinctive:

    Leave non-ASCII in text you did not write.

    line 157

“Common” is measured: kept by at least 6 in 10 of the 176 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Audit — both domains, whole project

The widest sweep in the toolchain. Code and docs are audited together and against each other, because the highest-value findings in both real runs of this skill lived in the gap between them: a doc asserting something disk contradicts, or a function whose name promises what its body does not do.

Which audit is this?

SkillDomain
auditcode + docs + the cross-domain pass
audit-codecode only
audit-docsdocs only

Scope is an argument, not a separate skill. Default is the whole project. Pass recent — /audit recent, or "audit what I just did" — to scope to work since a base ref. The methods are identical either way; only what they are pointed at changes.

Use audit when the user says "audit" with no qualifier. It is the default and the most expensive.

Not this skill

  • Did the change land where it actually executes? → landing-check. This skill hunts defects; it does not verify a deployment reached the live file.
  • Is this diff correct? → /code-review.
  • Did the code I just wrote run? → coding-conventions (fires on its own).
  • One narrow mechanical check → the specialist owns it, and this audit CALLS it rather than re-deriving it: cve-audit, history-leak-scan, local-secrets-manage, data-integrity-audit, path-quirk-audit, shell-portability, seed-control, determinism-guard, milestone-track.

Inputs

  • Scope — default: the whole project. Resolved by references/scoping.md, which also covers the case where the working directory contains several git repos rather than being one.
  • Driver, if stated (pre-launch, performance complaints, tech-debt sizing, pre-handoff) — weight the sweep toward it; never let it shrink the manifest.
  • Knowledge graph — if graphify-out/ exists, query it first to target the sweep instead of reading every file cold.

Protocol

Read each reference file as you reach its step. They hold the depth; this file holds the order.

1. Enter cold. An audit run by the session that built the thing inherits its author's belief, and "that module is fine, I wrote it" is not a finding you can make. If this session has already worked on the project, spawn a fresh auditor and hand it only what references/fanout.md permits. If the session is genuinely fresh, you ARE the cold auditor — proceed inline rather than spawning to re-derive what you do not yet believe.

Cold means unbiased, not amnesiac. Read the project's own docs — as claims under test, never as facts to assume, and never as a reason to skip a check.

2. Resolve scope and build the manifest. Per references/scoping.md. Produce an explicit file manifest: every file in scope, each assigned to at least one worker. The manifest is what turns "audited everything" into a claim you can prove rather than assert. Exclusions are listed with reasons (vendored node_modules/, generated output), never silently dropped.

Enumerate with git -c core.quotepath=false ls-files, never a $-anchored extension grep — that silently drops every non-ASCII filename, and on 2026-08-21 it cost a real run of this skill the single most important document in the tree. Reconcile the count against a second enumeration before trusting it.

If recent was passed, resolve the base ref instead and say which you chose: three-dot git diff base...HEAD (two-dot picks up base drift and is the classic wrong answer), plus uncommitted and untracked work, ranked by relative churn rather than absolute — R^2 = 0.811 versus 0.052 (Nagappan & Ball, ICSE 2005). Then walk the blast radius, which is mandatory, not optional: pull unchanged callers of changed symbols into scope, because that is where a broken contract actually surfaces. A recent-scoped report states its own blind spots — it cannot see pre-existing defects in untouched code, or a latent bug the change newly made reachable.

3. Fan out. Per references/fanout.md. Sonnet workers, eight maximum across all levels, including any delegates a worker spawns. Pre-register the acceptance rubric before any worker output exists. The session model synthesises and re-verifies; it does not merely relay.

4. Sweep — three method families.

  • Docs first — references/docs-methods.md (D-series). It is the cheaper sweep, and its claim inventory is a required input to the code sweep: running code first means tracing invariants nobody wrote down and checking intent against a spec you have not read.
  • Code — references/code-methods.md (M1–M9 plus the edge-case generators). Run in cost order; the cheap methods aim the expensive ones.
  • Cross-domain — references/cross-methods.md (X-series). The reason this combined skill exists. Run it LAST, because it consumes both sweeps' outputs.

5. Verify before reporting. Every crit and high is reproduced by the session model itself, with the command and its real output pasted. Everything else carries its tier. A zero-result search is a claim, not a fact — cross-check load-bearing negatives through a second implementation before believing them. That rule is in references/code-methods.md and it has bitten this project for real.

6. Report. Exactly the contract in references/reporting.md. No section invented, none silently dropped.

7. Wait for approval. the user replies "do all", "do 1 and 3", "do E1-E3". Then fix in the stated fix order, verifying each fix by running the thing — edge-case fixes are verified by feeding them their actual trigger, not by reading the patch — and report what was fixed versus skipped.

8. Follow-up validation. Re-run the automated pass and the affected tests to prove the fixes introduced no regressions. Report before/after.

Rules

  • The findings pass changes NOTHING. No drive-by fixes, no "improved while I was there".
  • Never delete anything you did not create this session without asking — a working tree often holds harmless stray files.
  • Never install new scanners without asking, and never claim regulatory compliance status. Flag gaps; do not certify.
  • Never invent a number, measurement, or timestamp. Run date before writing any timestamp. Missing data is reported as missing.
  • Every fix is surgical or it is honestly labelled large. Prefer one guard at the shared chokepoint over N guards at call sites — smaller diff and root cause at once.
  • Coverage is proven by the manifest, not by how thorough the sweep felt. A method not run is "not swept", never "no findings".
  • Keep tokens low per unit of coverage: sample large files, prefer grep and queries over full reads, and never paste long code excerpts into the report.

ASCII-only markdown (rule added 2026-09-23)

Every .md file this skill creates or writes to gets ASCII characters only (bytes 0x00-0x7F) in the text you add. No exceptions for headings, tables, quotes, names or pasted tool output.

  • Dashes: - (never an en or em dash). Arrows: -> and <-. Quotes: straight " and '. Ellipsis: .... Math: x, +/-, <=, >=, ~. Separators: -, ; or |. No emoji, no check-mark glyphs (use [x] and [ ]), no accented letters: transliterate names and quoted text.
  • Check before saving. In a git repo, git diff -U0 -- <file> | grep -v '^+++' | grep '^+' | grep -nP '[^\x00-\x7F]' must print nothing. For a new or untracked file, grep -nP '[^\x00-\x7F]' <file> must print nothing.
  • Leave non-ASCII in text you did not write. Earlier entries of an append-only record stay byte for byte; converting an existing file is a separate, explicit job.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.