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
- Laucked-Security/claude-oswetheir own version, first seen Nov 8, 2026
- sanmidable/skillstheir own version, first seen Nov 8, 2026
- alegauss/claude-traytheir own version, first seen Nov 8, 2026
- ansvisor/ansvisortheir own version, first seen Nov 8, 2026
- ai-search-guru/getcito-worlds-first-open-source-aio-aeo-or-geo-tooltheir own version, first seen Nov 8, 2026
- MammadovEshgin/clean-code-skilltheir own version, first seen Nov 8, 2026
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-hubSkilldelight
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-hubSkillteach-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
zwy123zwySkillnormalize
将用户随意输入的提示词规范化为结构清晰、便于大模型执行的标准化提示词。适用于需要整理、统一提示词格式时调用。
Also in 19 projects that use this
SkillPilotCHSkilllevel-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-aiSkillpm-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
Other versions194 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 194
- openai/plugins★ 7.8ksame name
- ccch1mneyyy/dsh-TUI★ 7.2ksame name
- macro-inc/macro★ 6ksame name
- yournextstore/yournextstore★ 5.5ksame name
- gadievron/raptor★ 4ksame name
- alchemy-run/alchemy★ 1.9ksame name
- alchemy-run/alchemy-effect★ 1.9ksame name
- mattmireles/gemma-tuner-multimodal★ 1.5ksame name
- jsmastery-pro/skills★ 1.4ksame name
- nateherkai/AIS-OS★ 1.4ksame name
184 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository34 other files it gives its agents.
- audit-codeSkill
- audit-docsSkill
- bisect-driverSkill
- coding-conventionsSkill
- commit-gateSkill
- compact-ioSkill
- cron-task-manageSkill
- cve-auditSkill
- data-integrity-auditSkill
- decision-logSkill
- deck-builderSkill
- determinism-guardSkill
- etl-validateSkill
- experiment-logSkill
- fetch-firstSkill
- flaky-test-detectorSkill
- github-repo-polishSkill
- golden-lockSkill
- history-leak-scanSkill
- landing-checkSkill
- llm-eval-harnessSkill
- local-secrets-manageSkill
- long-taskSkill
- milestone-trackSkill
- opus-workersSkill
- path-quirk-auditSkill
- reorg-proposalSkill
- research-briefSkill
- seed-controlSkill
- shell-portabilitySkill
- skill-vetSkill
- small-taskSkill
- token-squeezeSkill
- venue-fitSkill
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
- Very specific: line 25
Scope is an argument, not a separate skill: Default is the whole project.
- Very specific: line 30
Use audit when the user says "audit" with no qualifier.
- Distinctive: line 56
Read each reference file as you reach its step.
- Distinctive: line 107
5. Verify before reporting: Every crit and high is reproduced by the session model itself, with the command and its real output pasted.
- Distinctive: line 127
The findings pass changes NOTHING: No drive-by fixes, no "improved while I was there".
- Very specific: line 133
Never invent a number, measurement, or timestamp: Run date before writing any timestamp.
- Distinctive: line 135
Every fix is surgical or it is honestly labelled large: Prefer one guard at the shared chokepoint over N guards at call sites — smaller …
- Distinctive: line 140
Keep tokens low per unit of coverage: sample large files, prefer grep and queries over full reads, and never paste long code excerpts into …
- Very specific: line 145
Every .md file this skill creates or writes to gets ASCII characters only (bytes 0x00-0x7F) in the text you add.
- Very specific: line 153
Check before saving. In a git repo, git diff -U0 -- <file> | grep -v '^+++' | grep '^+' | grep -nP '[^\x00-\x7F]' must print nothing.
- Distinctive: line 157
Leave non-ASCII in text you did not write.
“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.
Files
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?
| Skill | Domain |
audit | code + docs + the cross-domain pass |
audit-code | code only |
audit-docs | docs 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
datebefore 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.
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
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.

