← ClaudeAtlas

garden-docslisted

Audit project documentation for staleness by comparing what changed in code since docs/ was last updated. Use this skill whenever the user mentions gardening docs, auditing docs, checking if docs are stale, syncing docs with code, doc drift, or asks "are the docs up to date". Also trigger when the user says things like "update the docs", "docs are stale", "what's missing from docs", or "review documentation freshness".
amittamari/hop · ★ 5 · Code & Development · score 70
Install: claude install-skill amittamari/hop
# Doc Gardening Detect documentation drift — code changes that happened after the last docs/ update — and fix it. ## Mental Model Documentation rots when code evolves but docs don't. The "drift window" is the set of commits between the last `docs/` change and HEAD. Every commit in that window is a potential source of undocumented change. The job is to read those commits, understand what changed structurally, and decide whether the existing docs still describe the system accurately. Not every code commit needs a doc update. Bug fixes, test additions, formatting, dependency bumps, and internal refactors that don't change boundaries or behavior are noise. The signal is: did a boundary move, did a module's responsibility change, did user-facing behavior change, did the data flow change, did a new concept appear that readers would need to know about. ## Workflow ### 1. Discover the drift window Find the last commit that touched any file under `docs/`: ```bash git log -1 --format="%H %ai %s" -- docs/ ``` Then find all commits since that one: ```bash git log --oneline <last-docs-commit>..HEAD ``` If `docs/` has never been touched, the drift window is the full history — flag this and suggest bootstrapping documentation first rather than gardening. If HEAD *is* the last docs commit (no drift window), report that docs are current and stop. ### 2. Analyze the drift window For each commit in the drift window, examine what changed: ```bash git diff --stat <last-docs-commit>