documentation-auditlisted

# Documentation Audit Sync the five formal docs (PRD/TECH/API/FLOW/TODO) to the code, then produce an audit report. Documentation must reflect reality — this skill brings drifted docs back into alignment and records what changed. ## When to use - A formal doc (PRD/TECH/API/FLOW/TODO) contradicts the current code - Documentation is stale or out of sync after a feature ship - Manual request to synchronize all documentation with the codebase - Writing new documentation from scratch (see `references/writing-docs.md`) **Not for:** open source GitHub presence polishing (use `oss-polish`); designing API contracts (use `api-design`); writing the PRD/TECH themselves (use `spec`/`architecture`). ## Steps ### 1. Discovery — locate the five formal docs and code structure Find every formal doc and map the codebase layout so later steps know where to look. ```bash # Locate the five formal docs (project-level) ls docs/PRD.md docs/TECH.md docs/TODO.md docs/API/*.md docs/FLOW/*.md 2>/dev/null # Version-level variants (if multi-version project) ls docs/v*/*.md 2>/dev/null # Detect API framework for the API drift step grep -Ei "express|fastify|@nestjs|fastapi|flask|django|gin|echo" package.json requirements.txt go.mod 2>/dev/null ``` Record which docs exist and which are missing. Missing docs are gaps to flag — not to create here (creation belongs to `spec`/`architecture`/`api-design`). ### 2. PRD & TECH drift — implementation vs spec Read the code's actual behavior and compare again