# Recipe: doc-drift checker

For anyone whose Build brief idea is still blank. Swap in your own systems and this is yours in ten minutes.

**The pain it copies:** documentation describes a system that has since moved on, and nobody notices until someone relies on the stale version. Jennifer's commissions system map and Thomas's service-documentation work both ran into this: the write-up is easy, knowing when it goes stale is the actual problem.

## The five blocks

- **Trigger:** a schedule (weekly is a reasonable start), or the event that changes the system: a merged PR, a config change, a deploy.
- **Input:** the documentation itself, plus the current state of the thing it describes: code, config, a live query, whichever is authoritative.
- **Work:** compare what the doc claims against what's true right now, and list the specific mismatches.
- **Check:** every flagged mismatch names the exact line or section that's wrong and what the current reality is, so a reader doesn't have to re-derive it.
- **Output:** a short drift report: what's stale, where, and (if it's obvious) what the doc should say instead.

## Swap in your own systems

- Pick one document you already know is a little out of date. That's your test case.
- "Current state" doesn't need to be live data. A recent export or a manual check is a fine starting oracle.
- To make the Trigger real: a weekly [Claude Code routine](https://code.claude.com/docs/en/routines), or a GitHub trigger on merged pull requests if the drift you care about follows code changes.

## Done when

It compared a real document against current reality, and named at least one genuine mismatch specific enough that someone could fix the doc without re-investigating it themselves.