Docs As Code Review — Claude Code Guide

Docs-as-code checks text like a code change

A documentation diff needs to be checked as carefully as code: do the claims match the repository, do the commands work, are there invented entities, and are there enough sources for the conclusions?

A convincing style is not proof of accuracy. The accepted document is one that can be checked reproducibly.

A document review rubric

1. Review git diff and the scope of the change.
2. Find every file, class, route, or command mentioned.
3. Check names with find, grep, or the IDE.
4. Copy the commands from the document and run them in the correct directory.
5. Remove or mark unverified claims.
6. Check the description of risks, constraints, and open questions.
7. Review the small, understandable diff once more.

find <directory> -name "<file-name>"
grep -R "<entity-name>" <directory>
git diff -- README.md docs/

Evidence-based run verification

docker compose up -d db
./gradlew bootRun
cd apps/web && npm run dev

Do not mix different reviews into one diff

• do not combine startup, API, architecture, and troubleshooting without a reason;
• do not duplicate unverified information across multiple documents;
• use API_MAP.md as an intermediate source for integrations;
• after manual checks stabilize, you can formalize them as a repeatable workflow.

The document readiness criterion

A document is ready when its claims have sources, its commands have been checked or explicitly bounded, invented entities are absent, and its list of assumptions and constraints is available to the reader. This docs-as-code approach makes documentation part of the engineering process rather than decorative text.