Auto-commit
By default ZAR proposes doc changes as a pull request. Auto-commit lets it skip the PR and write the fix directly. It’s powerful and intentionally hard to enable by accident.Two locks, both required
ZAR will commit doc updates only when both of these are true:- The repo setting
auto_commit_enabledis on. Toggle it with@docagent enable auto-commitor in the dashboard. - The operator has set
DOCAGENT_WRITE_COMMITSin the deployment’s environment.
Enable it
@docagent status.
Where commits land
Withuse_updates_branch on (the default), ZAR commits to a dedicated zar-updates/… branch and surfaces it as a PR rather than pushing straight to your protected branch. If you turn use_updates_branch off, ZAR commits to the PR head branch instead. Either way, branch protection rules still apply — ZAR can’t push where GitHub won’t let it.
When to use it
Auto-commit suits teams that have watched ZAR’s PRs for a while and trust the output, especially with a style guide dialed in. A good rollout:- Run with PRs only for a few weeks.
- Add a
style_guideand refine it. - Turn on auto-commit on one repo, with
use_updates_branchon, so commits still arrive as a reviewable branch. - Expand once you’re comfortable.
Interaction with other settings
- Dry-run wins. A repo in dry-run never commits, even with auto-commit on.
disable_prstops ZAR from opening PRs or committing entirely — a hard off switch.- Auto-commit doesn’t change significance or trigger decisions; it only changes how an approved change is delivered.
Next steps
- Commands —
enable auto-commit,status. - Safety & guarantees — why writes need two locks.
- Environment variables —
DOCAGENT_WRITE_COMMITS(self-hosting).