1. Start in a local project checkout
Install Node.js 20 or newer and open a terminal in the project you want to document. Check the runtime with node --version. The CLI runs in Node. It does not start, import or execute the application being inspected.
A clear README helps the generated overview describe the project's actual purpose. Source declarations and package manifests provide the technical structure. Dependencies, generated output and common secret files are excluded, so the output is not an inventory of every file on disk.
2. Generate documentation from code
npx @autodocify/autodocs analyze .The dot selects your current directory. To inspect another checkout, replace it with that project's path. The first npx invocation may download the package from npm. The source analysis itself runs locally.
Run this in a working tree where you can inspect the diff. The analyzer writes files into the selected project's docs directory. If those filenames already exist, save any hand-written content before regenerating them.
3. Review the three Markdown files
Read the overview as someone new to the product, then read the architecture file as a developer joining the project. Look for missing components, ambiguous names and setup instructions that need more context.
- docs/overview.md: the project-facing introduction and detected capabilities.
- docs/architecture.md: stack, source components, dependencies, declared routes, data models and detected local commands.
- docs/er-diagram.md: a Mermaid ER diagram and field reference for supported model declarations.
4. Check claims against the implementation
Static source analysis cannot prove that an endpoint works, that a database connection succeeds or that the application follows a particular runtime path. Dynamically assembled routes and unsupported schema patterns can be incomplete.
Open the related source when a result is surprising. Add deployment requirements, architectural tradeoffs and business rules yourself. These are often the most useful parts of documentation, but they should not be invented from filenames.
5. Commit and maintain the reviewed result
Review git diff for docs/ before committing. Keep the generated files alongside the code so reviewers can compare documentation changes with implementation changes.
After a route, model or dependency change, rerun the command and review the new output. Keep additional hand-written decisions in separate files if you want them to remain independent of regenerated Markdown.