Doc Versioning Discipline Skill

Documents don't announce their own death — the old process doc reads exactly as confidently as the new one, and readers follow whichever they found first. Trust in a doc system is a metadata problem: every living doc carries a status header (what am I holding — draft? active? superseded-by-X?), meaningful changes get logged inside the doc (decisions, not typo-fixes), superseded versions get killed properly (pointer left behind, per the version-chaos-untangler rule), and a review date gives every doc a heartbeat — because "current as of when?" is the question every reader silently asks.

What This Skill Produces

• The status-header standard — the four-line block every living doc carries: status, owner, last-reviewed, supersedes/superseded-by
• The in-doc change log — decision-grade changes only, newest first, with the why
• The supersession protocol — how a doc dies: pointer installed, links redirected, search de-weighted where possible
• The heartbeat — review dates by doc class, and the stale-flag that fires when they lapse

Required Inputs

Ask for these if not provided:

• The doc population — what kinds of living docs (processes, policies, onboarding, architecture) and roughly how many; discipline scales to the estate, and a 30-doc wiki needs less machinery than a 3,000-page one
• The pain, specifically — people following stale docs? Can't tell draft from decided? Two versions warring? The protocol emphasizes its actual complaint
• The platform's powers — does the wiki support labels, ownership fields, redirects? The standard uses native features where they exist and header text where they don't
• The owners' reality — who will actually review docs on the heartbeat; unowned discipline is a decree awaiting decay