Skip to content
BoB — Big ol' Brain

Documentation Audits

Documentation Audits

Section titled “Documentation Audits”

This directory holds drift reports produced by the doc-keeper agent (#151). The reports tell readers which docs are current, which are stale, and which need archiving.

Canonical paths

Section titled “Canonical paths”
  • latest.md — the most recent drift report (markdown). The docs site (#153) reads this for its landing-page badge.
  • latest.json — same report in machine-readable form (#156). Downstream tooling reads this.

History

Section titled “History”

Date-stamped reports are kept here so the docs-vs-code drift can be seen over time:

File Generated by Notes
doc-audit-YYYY-MM-DD.md /doc-audit Human-facing report for a specific run
doc-audit-YYYY-MM-DD.json /doc-audit Machine-readable counterpart

Re-running on the same day overwrites both that day’s date-stamped files and latest.{md,json} — deterministic by date.

How a report gets here

Section titled “How a report gets here”
/doc-audit
  ├── runs scripts/doc-keeper/audit.js across docs/, README.md, CLAUDE.md
  ├── writes doc-audit-YYYY-MM-DD.{md,json}
  └── copies them to latest.{md,json}

Rendering on the site (#156)

Section titled “Rendering on the site (#156)”

The docs site reads docs/audits/latest.md and surfaces:

  • A “Docs last verified” date on the landing page (from the report’s generated_at).
  • An “Audits” entry in the site nav linking to this directory.
  • Per-doc verified/needs-update/archive badges (consumed from latest.json).
  • A history page indexing every date-stamped report in this directory.

The nav + landing-badge component wiring for the docs-site engines (VitePress / Starlight) is a follow-up — see #156. The data plumbing (latest.{md,json} aliases + history) is already in place.

Memory audits (#342)

Section titled “Memory audits (#342)”

The /memory-audit skill writes its drift reports here too (memory-audit-YYYY-MM-DD.{md,json} plus memory-latest.{md,json}). Unlike the documentation reports above, these describe the user’s private per-project memory (memory slugs, home-relative paths), so they are gitignored — generated on demand and kept local, never committed.

See also

Section titled “See also”