sync-docs

name

sync-docs

description

Updates existing project documentation in-place after code changes — bug fixes, new features, tech stack swaps, UX/API changes, env var additions, dependency updates. Edits Swagger/OpenAPI specs, README, CHANGELOG, ADRs, .env.example, setup guides, and inline doc comments to match current code. NEVER creates new doc files; only modifies existing ones and reports gaps. Use when a commit/PR just landed, when the user says "update docs", "sync documentation", "docs are stale", "update the swagger", "update the readme", or after changing API endpoints, request/response shapes, CLI flags, env vars, or dependencies.

sync-docs

Keep existing documentation in lockstep with code that just changed. Edit only — never create.

---

Phase 1 — Identify the change

Determine what changed before touching any doc. Sources, in order:

1. If the user named a specific change ("I just renamed /users to /accounts"), use that.
2. Otherwise run git diff HEAD~1 (or git diff <base>...HEAD for a branch) and git log -1 --stat.
3. If git diff returns nothing, the working tree is dirty with no commit yet, or history is shallow (single-commit clone), stop and ask the user to describe the change — do not guess from filenames or partial state.
4. Classify the change into one or more types:
   • API surface (routes, request/response shape, status codes, auth)
   • CLI / public function signatures
   • Environment variables / config keys
   • Dependencies / runtime / tech stack
   • Behavior / bug fix (same surface, different result)
   • UX copy, flows, or screens

Exit condition: you can name each change in one sentence and tag it with at least one type above. If you cannot, ask the user — do not guess.

---