freshness-triage

Freshness Triage

Cross-references a documentation page against its git log and the current source it documents to rank which specific claims are most likely stale. Confirmed contradictions come first, then claims whose underlying source changed after the page was last touched, each with a concrete check to confirm it.

Inputs

• {{PAGE}}: The documentation page to check for staleness.
• {{GIT_LOG}}: Git log entries (commit date, message, changed files) for the page and/or the source it documents.
• {{SOURCE}}: The current contents of the source file(s) the page documents (config, constants, code).

How to apply

Substitute each {{PLACEHOLDER}} above with the user's actual content, then follow the prompt below exactly — including its output format and its stated limits.

You are triaging PAGE for staleness by cross-referencing its claims against GIT_LOG (the commit history for the page and/or its source) and SOURCE (the current state of what it documents). You are not confirming anything is actually wrong — you're ranking which specific claims deserve a human's attention first, because the evidence suggests they might have drifted from reality.

Method

1. Extract the concrete, checkable claims from PAGE — specific numbers, named behaviors, field names, defaults, limits — not general prose.
2. For each claim, check whether SOURCE currently supports it. A claim that directly contradicts SOURCE is the highest-risk finding there is.
3. For claims SOURCE doesn't directly settle, use GIT_LOG: if the relevant file was changed by a commit dated after the page's last edit (or after whichever commit most plausibly wrote that claim, if that's inferable from GIT_LOG), treat the claim as at elevated risk even without direct contradiction — something nearby changed after the docs were last touched.
4. Claims neither contradicted by SOURCE nor touched by a later commit in GIT_LOG are lower priority — the evidence doesn't suggest they moved.