Docs rot. You rename a function, change a default, drop an endpoint, and the README keeps describing the old behavior. Nobody notices until a new teammate follows the docs and hits a wall.
ZAR is a GitHub App that keeps a repository's documentation accurate as the code evolves. It works where you already review code: inside the pull request.
What ZAR does
ZAR listens to GitHub events (push, pull_request, issue_comment). When code changes, it analyzes the diff plus best-effort AST and symbol changes, then asks Claude to propose minimal unified-diff patches to your Markdown docs (README.md, docs/**/*.md).
It posts those proposals as clear PR comments. You read them the same way you read any review note, and you decide what to merge.
Two principles drive the whole thing:
- Be conservative. Minimal diffs. Never invent facts in docs.
- Be PR-native. Output is readable in a GitHub comment, not a separate dashboard you have to remember to open.
How a typical run looks
You open a PR. ZAR sees the diff, spots that a documented symbol changed, and comments with a patch like this:
--- a/README.md
+++ b/README.md
@@ -42,7 +42,7 @@
-Call `charge(amount)` to bill the default currency.
+Call `charge(amount, currency)` to bill in a specific currency.
If the patch is right, apply it. If it is wrong, ignore it. Nothing changes in your repo unless you say so.
It never writes by default
This matters enough to repeat. ZAR proposes. It does not auto-fix your repo behind your back.
- Writing docs back into the repo is off by default, gated by both an environment flag and a per-repo setting.
- Dry run mode is a hard guarantee: it never commits and never blocks a merge. It only reports what it would do.
If you want stronger guardrails, you can opt in to a CI gate. ZAR sets a zar/docs commit status (success / pending / failure) so stale docs can show up as a check, the same way tests do.
Controls you can turn on
ZAR ships with knobs, all opt-in:
- Trigger modes: every commit, on significant change, daily, or on merge.
- CI gate: labels and check-runs that surface stale docs at review time.
- Auto-commit: let ZAR push approved doc patches, only when you explicitly enable it.
- Style guide: describe your docs voice in plain language and ZAR follows it.
- Natural-language commands: talk to ZAR in a PR or issue comment to steer a run.
Why review time
Docs drift is cheapest to fix at the moment the code changes, while the author still has full context. A week later, the person who renamed charge() has moved on and nobody remembers why the old example is wrong.
ZAR puts the doc fix next to the code change, in the same review, so accurate docs become part of merging instead of a chore for later.
That is the whole idea. Code changes, docs follow, and you stay in control of every edit.