audit

A read-only checker for a documentation-led software repository, where written rules guide development and architecture decisions are kept as ADRs.

In plain words
What is it for?
Use it to check ADR numbering, catalogue entries, plans, required sections, language rules, cross-references, and accidental decision details in user-facing code.
Why use it?
It finds mismatches between the repository’s rules and its files, such as missing documents, numbering gaps, invalid statuses, or broken links.

Skill for Claude CodeCodex

Install

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.

agentmods
npx agentmods add skills/evolvehq/docflow/audit
Any agent
npx skills add EvolveHQ/docflow --skill audit
Clone the repo
git clone --depth 1 https://github.com/EvolveHQ/docflow

Made for: Claude Code, Codex.

Per session 145 Skills are progressive disclosure: only the name and description are preloaded; the body loads when the skill is used.
When invoked 2,025 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

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.

ModelPer sessionOnce invoked
Fable 5 $0.00145 $0.02025
Opus 5 $0.00072 $0.01012
Sonnet 5 $0.00029 $0.00405
Haiku 4.5 $0.00015 $0.00202

Measured 2d ago against content hash a262fed33967, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

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 2d 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.

plugins/docflow/skills/audit/SKILL.md · 136 lines

How it starts

The opening of the file, as written. The whole thing — 136 lines — stays where its author put it; the contents beside it link to each section on GitHub.

audit

Check a documentation-led repo against the conventions it declares. This is the enforcement AGENTS.md cannot guarantee on its own.

Step 0 — Preconditions and context

  1. Confirm the repo is bootstrapped.
  2. Read CONVENTIONS.md to learn what to enforce: ADR shape and cutoff, status lifecycle, integration model, multi-agent mode, language mandate, optional artefacts present (GLOSSARY, domains/), and any Q10 domain hard rules, and the artefact root (default: repository root) — resolve adr/, plan/, INDEX.md against it and honour it in the cross-reference and INDEX-sync checks.
  3. If a federation.md exists, this repo is part of a multi-repo product. Note its Role (central / home / coordinator index-holder, or a plain member) and read the recorded identity scheme; the cross-repo checks (check 12) run from the index-holding repo.

Step 1 — Run the checks (read-only)

Report each as PASS / FAIL / N/A with specifics (file + line where relevant):

  1. Numbering. ADR filenames contiguous, zero-padded, no gaps, no duplicates. Split repos: capability below cutoff, technology at/above.
  2. INDEX sync. Every ADR appears in INDEX.md; every INDEX row has a matching file; metadata fields (status, title, date) agree.
  3. Plan coverage. Every Accepted ADR has a plan/todo/ item; every Implemented ADR has a plan/done/ entry. Flag orphans both ways.
  4. Section completeness. Each ADR has the required sections in the order its shape mandates. Acceptance criteria are numbered.
  5. Status validity. Every status: is in the declared lifecycle. Superseded ADRs name a successor in superseded-by:; the successor names them in supersedes: (symmetry).
  6. Revision/Approvals. Revision History present; Approvals populated for ADRs at Accepted or beyond.
  7. Cross-references. Relative adr/NNNN-*.md links resolve to real files. Glossary anchors (if used) resolve.
  8. Language mandate. If set, spot-check user-facing docs for the required spellings.
  9. ADR-privacy leaks. Grep source / product directories for ADR identifiers in user-visible strings — patterns like ADR 0042, adr-0042, see ADR, ADR titles — in UI copy, API responses, error messages, customer-facing logs, public docs, release notes. Report each suspect; this rule is easy to violate by reflex.
  10. Coordination hygiene. N/A if _agent/ was omitted at bootstrap (Q5 = None). Otherwise: _agent/LOCKS.md has no stale claims (mode 2); _agent/IN_FLIGHT.md rows match live worktrees (mode 3).
  11. Cross-worktree collisions (mode 3, or when auditing across unmerged branches). These catch semantic conflicts that a line-level git merge cannot:
    • Duplicate ADR or plan/todo numbers — two ADR files, or two plan/todo/ items, (across branches/worktrees) claiming the same NNNN. Distinct from check 1, which only sees one tree. This is the collision the concurrency guardrails (G2 pre-merge / G3 gate) guard against; flag it so the later author renumbers.
    • Duplicate plan ownership — two plan/todo/ items naming the same owning ADR for the same scope, i.e. two worktrees building the same thing.
    • Same ADR edited on two unmerged branches — compare ADR files across the live worktrees / open PRs; flag any ADR modified in more than one. A merge=union would concatenate them silently. Cross-check against _agent/IN_FLIGHT.md: every collision should correspond to a reservation/ownership violation recorded there.
  12. Cross-repo (federation) checks — only when a federation.md exists; run from the index-holding repo (Role: central, home, or coordinator — whichever holds federation-index.md). Reach each member through the local checkout named in federation-index.md. A member not checked out locally is reported "unverified this run" — never silently passed, never a hard failure.
    • Bidirectional membership. Every repo listed in the member index carries a federation.md back-pointer to this index-holder, and every repo whose back-pointer names this repo is listed in the index. Flag either half-edge (in-index-without-back-pointer, or points-here-but-unlisted).
    • Identity collisions. Under the repo-prefixed scheme an identity is repo-id + local number, so the only reachable collision is a duplicate repo-id. Flag any repo-id that appears on more than one federation-index.md row or in two members' federation.md back-pointers.
    • Dangling cross-repo references. Resolve each cross-repo link along repo-id → Pointer → adr/NNNN-*.md — look up the repo-id's Pointer in federation-index.md, then the ADR file under that repo. A repo-id with no index row is a dangling reference. If the row exists but the checkout is absent, report it "unverified this run" (not dangling); only an absent ADR in a present checkout is a true dangling reference. (Same-repo relative links are check 7.)
    • Roll-up drift. The roll-up agrees with each member's INDEX.md metadata; flag rows that are stale, missing, or extra.
    • Convention drift. Compare each member's shared conventions against the index-holder's authoritative copy; flag a member whose shared conventions have drifted from the source. Members' local-only conventions are exempt.
  13. Coverage (undocumented developments). A heuristic nudge, not a precise diff: scan the major modules / top-level source directories and the recent git log for substantial behaviour or an area with no owning ADR — a large feature, subsystem, or dependency the catalogue never records. Report each as a prompt to capture it (reconstruct the decision as an Implemented ADR + plan/done, per the backfill path), not as a hard failure. Because the audit is doc-centric, keep this conservative — flag clear, sizable gaps, not every file.
  14. Artefact-root discovery. If a .docflow file exists at the repository root, its root: line must agree with the artefact root recorded in CONVENTIONS.md, and it must not redundantly name .docflow/ (the directory is its own marker — flag the file for removal). If the artefact root is not .docflow/ and no pointer file exists, surface it as an offer to add one (external tools discover the catalogue through it) — never as a hard failure; migration is offered, not forced.

Read the full file on GitHub · 136 lines

Files

What ships with it

1 file 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.

Changes

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.

  1. 2d ago First seen · 136 lines · 145 tokens per session scan A a262fed33967

Subscribe to this mod's changes

audit is a skill published in the GitHub repository EvolveHQ/docflow (10 stars, last pushed 27d ago), licensed MIT. It adds 145 tokens to every session and 2,025 once invoked, about $0.0007 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-08-31.

Related

Other skills, from other repositories

adr-integration

This skill should be used when the user asks about "ADR integration", "ADR CI/CD", "ADR tooling", "ADR automation", "export ADRs", "ADR documentation site", or needs guidance on integrating ADRs with CI/CD, documentation sites, and other tools.

zircote-plugins/adr · 59 tokens

adr-format-structured-madr

This skill should be used when the user asks about "structured MADR", "structured-madr", "frontmatter ADR", "comprehensive ADR", "auditable ADR", or needs guidance on creating ADRs using the Structured MADR format with YAML frontmatter and audit sections.

zircote-plugins/adr · 63 tokens

adr-decision-drivers

This skill should be used when the user asks about "decision drivers", "architectural forces", "quality attributes", "how to identify trade-offs", "non-functional requirements for ADRs", or needs help identifying, documenting, and weighing the forces that influence architectural decisions.

zircote-plugins/adr · 60 tokens

adr-fundamentals

This skill should be used when the user asks "what is an ADR", "when should I create an ADR", "ADR best practices", "architecture decision records", "ADR lifecycle", "how to document architecture decisions", or needs guidance on ADR fundamentals, when to create ADRs, or ADR lifecycle management.

zircote-plugins/adr · 68 tokens

adr-quality

This skill should be used when the user asks about "ADR quality", "review ADR", "ADR checklist", "improve ADR", "ADR validation", "good ADR examples", or needs guidance on evaluating, improving, and maintaining high-quality architectural decision records.

zircote-plugins/adr · 55 tokens

adr-compliance

This skill should be used when the user asks about "ADR compliance", "architecture compliance", "ADR audit", "enforce ADRs", "check code against ADRs", "ADR violations", or needs guidance on auditing code compliance with accepted architectural decision records.

zircote-plugins/adr · 56 tokens