Methodology for validating documentation against codebases. Covers document type lifecycles, review steps, evidence gathering, and structured output. Use when reviewing whether documentation (proposals, plans, architecture docs) accurately reflects what the code actually does. Triggers when user says "validate this doc", "is this documentation accurate", "check docs against the code", "audit documentation", or wants to verify that written documentation hasn't drifted from the implementation.
From project-docsnpx claudepluginhub ichabodcole/project-docs-scaffold-template --plugin project-docsThis skill uses the workspace's default tool permissions.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Retrieves current documentation, API references, and code examples for libraries, frameworks, SDKs, CLIs, and services via Context7 CLI. Ideal for API syntax, configs, migrations, and setup queries.
Uses ctx7 CLI to fetch current library docs, manage AI coding skills (install/search/generate), and configure Context7 MCP for AI editors.
A systematic approach for validating technical documentation against codebases. Use this methodology when reviewing documents for accuracy, implementation status, or archival readiness.
Different document types follow different lifecycles. Apply the appropriate rules based on what you're reviewing.
These documents have a lifecycle that ends in archival.
Project Pipeline Documents (docs/projects/<name>/)
Proposals, plans, and sessions live together in project folders. They share a lifecycle and are archived as a unit.
docs/projects/<name>/proposal.md)
docs/projects/<name>/plan.md)
docs/projects/<name>/sessions/*.md)
docs/projects/_archive/<name>/ when
all work is complete**Status:** Archived (Implemented) or
**Status:** Archived (Superseded by X)Investigations (docs/investigations/)
docs/investigations/_archive/**Status:** Complete - [outcome]Reports (docs/reports/)
docs/reports/_archive/These documents are living and should be updated rather than archived.
Architecture (docs/architecture/)
Specifications (docs/specifications/)
Interaction Design (docs/interaction-design/)
Playbooks (docs/playbooks/)
Lessons Learned (docs/lessons-learned/)
Fragments (docs/fragments/)
Search for evidence using multiple techniques:
git log --oneline --all --grep="[keyword]" for related
commitsdocs/projects/*/sessions/ for implementation notesFor Temporal Documents (proposals, plans, investigations):
For Evergreen Documents (architecture, playbooks, etc.):
For each finding, cite specific evidence:
Structure your findings consistently:
## Document Review: [filename]
**Document Type:** [Proposal | Plan | Investigation | Architecture | etc.]
**Current Status in Doc:** [What the document currently says] **Actual Status:**
[Your determination] **Completion:** [100% | 75% | 50% | etc. - for temporal
docs]
### Summary
[1-2 sentences on what this document describes]
### Findings
**Implemented:**
- [Feature/item] - Evidence: `path/to/file.ts` (lines X-Y)
- [Feature/item] - Evidence: commit `abc123`
**Not Implemented / Missing:**
- [Feature/item] - No code found for X
- [Feature/item] - Partially done: [what exists vs what's missing]
**Outdated / Incorrect:**
- [Section] claims X but code shows Y
- [File path] no longer exists, moved to Z
### Recommendation
**Action:** [Archive | Update Status | Update Content | No Action]
**Specific Steps:**
1. [Exact action to take]
2. [Another action]
**New Status:** `**Status:** [recommended status text]`
Before returning findings: