process-docs

Identify the doc surface for each change, update the existing canonical doc rather than creating a new one, and validate that commands, paths, and links still work. Finish by stamping the doc with a Last updated date and checking downstream docs for duplicated content.

End-user docs belong in docs/runbooks or docs/guides, developer docs in docs/architecture and README files, AI agent instructions in AGENTS.md and skill files, and operational content in docs/ops or infra directories.

Update docs as you write code, not after the feature is complete. Trigger doc updates whenever you change an API, schema, or architectural boundary, create a new skill or runbook, or modify workflows described in READMEs.

Avoid copy-pasting sections between docs, writing vague commands instead of exact ones like npm run build:server, mixing end-user and internal API content in one doc, and leaving docs without a Last updated date, which makes them appear stale.

Skip doc work for one-line code changes with no contract impact, temporary scratchpad notes, or content that duplicates an existing canonical doc. In those cases, update or link to the source of truth instead.