Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add ai-driven-dev/framework --skill 04-auditgit clone --depth 1 https://github.com/ai-driven-dev/frameworkWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/ai-driven-dev/framework/04-audit)<a href="https://agentmods.dev/skills/ai-driven-dev/framework/04-audit"><img src="https://agentmods.dev/badge/skills/ai-driven-dev/framework/04-audit.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00054 | $0.00610 |
| Opus 5 | $0.00027 | $0.00305 |
| Sonnet 5 | $0.00011 | $0.00122 |
| Haiku 4.5 | $0.00005 | $0.00061 |
Grade A, and why
04-audit scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 38 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Skill: audit
Diagnose a codebase against quality pillars and emit one ranked findings report. Read-only: it identifies and ranks problems, never changes code.
Actions
| # | Action | Pillar | Lens |
|---|---|---|---|
| 01 | code-quality |
code-quality | Clean code (naming, SOLID, DRY, readability, smells) and tech debt (dead code, complexity, file/function size, error handling) |
| 02 | architecture |
architecture | Conformance to C4 / ADRs, coupling, boundaries, layering |
| 03 | security |
security | OWASP risks, authz, input validation, secrets in code |
| 04 | dependencies |
dependencies | CVEs, licenses, outdated and unused deps, supply chain |
| 05 | performance |
performance | N+1 queries, hot paths, bundle size, heavy operations |
| 06 | tests |
tests | Critical-path coverage, flakiness, test pyramid balance |
| 07 | ui |
ui | Loading/error/empty states, visual hierarchy, design-system drift, responsive, a11y |
Run the one pillar named, or offer all seven when the request is unscoped.
Before running an action, read its file in actions/, not only the table or assets.
Transversal rules
- Read-only: diagnose and rank, never edit code.
- Scope: run the one named pillar, or for an unscoped request ask once "all seven pillars, or one?" before running. Never silently default to one pillar, never blind-run all without offering the choice.
- One folder per run,
aidd_docs/tasks/<yyyy_mm>/<yyyy_mm_dd>_audit/, like a feature folder. Every pillar that runs always writes its own<pillar>.mdthere, alone or in a full run. A full run additionally writes a mergedreport.md: one Findings table (category = pillar, severity-first), one Top-actions list, and one Coverage section over all seven pillars. - Unscannable pillar: skip it, record it under
Coverage > Skippedwith the reason, and never invent findings for it. - Every finding row carries a severity, its pillar, a concrete
file:line, the issue, a suggested fix, and an effort.
What ships with it
8 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 38 lines · 54 tokens per session scan A f14dddb4226c
04-audit is a skill published in the GitHub repository ai-driven-dev/framework (455 stars, last pushed today), licensed MIT. It adds 54 tokens to every session and 610 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
doctor
Diagnose and repair your TinyFish setup — MCP registration, auth, and connectivity. Runs the TinyFish CLI's own doctor for the config checks, then does the one thing the CLI cannot — proving this harness can actually reach TinyFish. Run when TinyFish tools fail, return auth errors, or after an install that did not…
feedback
File structured feedback about TinyFish — bug reports, confusing setup steps, missing features, or a doctor diagnostic report. Creates a GitHub issue on tinyfish-io/tinyfish-cookbook with the user's approval; nothing is sent without an explicit preview.
performance-optimization
Measure-first performance work. Use on triggers like "it's slow", "profile this", "optimize perf", "fix the bottleneck", "improve load time / Core Web Vitals", or when a measured regression needs fixing. Enforces measure-before-optimize. Fills a perf gap not covered by existing project skills. Not a build/ship…
ci-troubleshoot
Diagnose failed GitHub Actions runs for pi-agent-dashboard: the 10-file workflow taxonomy, the release pipeline, known failure modes, and how to read gh run logs and retrigger jobs. Use when a CI run is red, a release is stuck, a workflow won't dispatch, or you need to know which workflow does what. See release-cut to…
debug-dashboard
Diagnose problems in the running pi-agent-dashboard system: server.log, /api/health, bridge WebSocket connectivity, vitest triage, known-issue FAQ entries. Routes UI/visual issues to the browser skill. Use when the server seems hung, a pi session won't connect, tests fail mysteriously, the dashboard shows a blank…
node-inspect-debugger
See runtime state a console.log cannot reach — set real breakpoints, step, and dump the scope chain of a paused Node/TypeScript process. Use on "set a breakpoint", "inspect runtime state", "console.log isn't enough", "step through this", "what's in this closure at runtime", "attach a debugger". Not a logging or…