Documentation Updater

When to use

• A change alters how to run/test locally (development environment setup, containerization, bootstrapping).
• You add/remove/change environment variables, secrets, or configuration files.
• You change environment/deployment assumptions used by scripts or tools.
• You add/modify operational scripts (deployment, data seeding, logging, maintenance tasks).
• You update integrations with external services or APIs.
• You modify infrastructure setup or deployment processes.

Principles

1. Prefer updating existing docs over adding new ones. Add a new doc only when it clearly reduces confusion.
2. Keep docs executable. Commands must match actual scripts/tools; paths must match the project structure.
3. Respect environment requirements. When docs tell users to run commands/tests, include the correct environment setup steps (e.g., sourcing environment files, activating virtual environments, loading configuration).
4. Document "what & why", not internal trivia. Focus on user outcomes and maintenance workflows.
5. Cross-link instead of duplicating. Use references to maintain a single source of truth.

Workflow

1) Determine doc impact from the change

2) Update the smallest set of docs that restores accuracy

• Update only the relevant sections; avoid broad rewrites.
• Keep headings and tone consistent with the existing file.
• Prefer adding links from main documentation to detailed reference docs for deep dives, instead of duplicating instructions.

3) Add "quick verification" steps

• The exact command(s) to run (use project-standard task runners or scripts).
• The expected output/behavior at a high level (1–2 bullets).
• Any common failure mode and how to fix it (1 short subsection max).

4) Check for drift and broken references

• Confirm referenced scripts/commands exist in the project.
• Confirm file paths and directory references exist in the repository.
• Verify external links are still valid and accessible.