reviewing-doc-drift

Verify documentation claims against actual shipped code behavior.

Updated Mar 30, 2026
One-click install
npx skills add https://github.com/ZaxbyHub/ragappv3 --skill reviewing-doc-drift-zaxbyhub
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: reviewing-doc-drift
Source: https://github.com/ZaxbyHub/ragappv3/tree/main/.claude/skills/reviewing-doc-drift
Command: npx skills add https://github.com/ZaxbyHub/ragappv3 --skill reviewing-doc-drift-zaxbyhub

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Documentation, release notes, and changelogs often drift away from what the code actually does, leading to overstated features, undocumented breaking changes, and examples that fail when followed literally. This Skill systematically detects that drift before it reaches users. ## Core Features & Use Cases - Claim Extraction and Verification: Pulls atomic claims from READMEs, changelogs, release notes, PR descriptions, examples, and docstrings, then locates structural proof in code, tests, routes, exports, and migrations. - Classification of Drift: Labels each claim as SUPPORTED, PARTIALLY_SUPPORTED, UNSUPPORTED, CONTRADICTED, or STEALTH_CHANGE, emitting defects only for material mismatches. - Targeted Checks: Verifies feature, resilience, caching, security, compatibility, and breaking-change claims, including whether renamed routes are imported safely via router objects. - Use Case: Before publishing a release, run this Skill against your changelog and README to confirm every announced feature maps to real handlers and that no undocumented breaking change slipped in. ## Quick Start Review the README and latest changelog entries against the current codebase and report any unsupported or contradicted feature claims.

Frequently Asked Questions about reviewing-doc-drift

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if my README matches my code?▼

Extract each feature claim from the README, then locate structural proof in code such as handlers, routes, exports, or tests. Claims without matching implementation are flagged as unsupported, and shipped behavior missing from docs is flagged as a stealth change.

How to verify changelog entries before a release?▼

Map each changelog bullet to the actual changed behavior in the codebase, confirming the release scope matches what shipped. Breaking changes must have migration notes, and renamed routes should be checked for direct imports of models or hardcoded paths.

What counts as documentation drift in a codebase?▼

Drift includes features claimed in docs but not implemented, behavior shipped but never documented, examples that fail when followed literally, and security or caching claims with no corresponding enforcement or invalidation logic.

Does renaming an API route break consumers?▼

Renaming is safe when consumers import only the mounted router object. It breaks when consumers import individual Pydantic models, named response-model classes, or hardcoded path strings directly, so those import patterns must be checked.

When should documentation drift checks run?▼

Run them before releases, when merging PRs that touch public APIs or docs, and during periodic documentation audits. They are most valuable when changelogs, migration notes, or user-facing examples change alongside code.