The wiki-watcher keeps a wiki in sync with its source repo automatically. Your docs track your code instead of drifting. It watches your repo's docs and code for doc-worthy changes. It looks at PLAN.md, ROADMAP.md, designs/, ADRs, tracked .md, and source files. When it finds a change, it dispatches the documenter to author the wiki update and open a PR for review.

It is an idempotent single-cycle engine you run on a loop. Each invocation runs one detect → judge → author → dispatch cycle and exits. You re-invoke it with Claude Code /loop or cron. This keeps your wiki up to date asynchronously as you work. Cursors and a processed-set make repeated runs safe.

This is the async path. It is distinct from the synchronous path. The synchronous path is the phase-boundary dispatch built into the development-lifecycle commands. The commands /plan, /work, /release, and /bugfix run the same documenter in-session the moment a phase completes. The watcher reuses that documenter on a loop for doc-worthy changes outside a phase boundary. This covers work outside the harness flow, or a repo you are not driving through the phase commands. That is why it runs decoupled, autonomous, and PR-gated. To drive it, see How to run the wiki-watcher. For the rationale, read the design.

There is no dedicated config file. The watcher reads three sources. Each source lives with the layer that owns it. The device config says whether the watcher may run at all. The per-repo marker says how it runs. The vault's repo registry says which wiki it writes to. Run config never lives in the vault. The vault carries the cross-device index. Everything about how this machine runs stays on this machine.

The watcher reads all three defensively. An absent, unreadable, or malformed source resolves to its safe default (disabled / skip). It never throws an error.

The device toggle is a plain on/off switch. The watcher reads it without touching the vault. The install prefix resolves from $AGENTM_INSTALL_PREFIX (default ~/.claude). You can use two shapes. The nested block is canonical. The top-level key is an alias:

{ "wiki_watch": { "enabled": true } }   // canonical
{ "wiki_watch_enabled": true }          // alias shorthand

The watcher dispatches autonomously. Enablement is opt-in. An absent, unreadable, or falsey config resolves to disabled.

The marker is a small per-repo file carrying the run config. Its presence is the per-repo opt-in. If you omit the marker, the watcher skips that repo. If you write a malformed marker, the watcher logs to stderr and then skips.

{
  "watch_sources": ["PLAN.md", "designs/"],   // repo-relative paths / globs
  "dispatch_mode": "pr"                         // "pr" | "direct"
}

Dispatch. The documenter authors its changes on a branch. Next, the cycle commits, runs the PII guard, pushes, and dispatches by mode:

Every git / gh step graceful-skips on failure.

The registry says which wiki a watched repo writes to. The registry is located at <vault>/_meta/repos.json. It carries an optional per-entry wiki_path. The watcher matches the repo by root_path (precedence) or slug. Then it resolves the path:

Resolution shells out to agentm's repo registry. When agentm is unreachable, it graceful-skips. The watcher no-ops rather than failing. The agentm kernel is not folded into crickets.

Run state lives in the project's own desk/, under a wiki-watch/ leaf: <vault>/projects/<slug>/desk/wiki-watch/, as agentm names it (project_homes.py home desk). With no desk — agentm absent, no vault for the project, or a desk that does not exist — a cycle skips the repo and writes nothing; there is no repo-local fallback. You will find three files:

Candidates face a coarse significance pre-filter before they reach the doc-worthiness judge. This filter drops obvious noise. It drops generated, vendored, and transient trees (.git, __pycache__, node_modules, dist, build, .venv, lockfiles, *.pyc, *.min.js, …). It also drops the output wiki/ tree. Watching the documenter's own writes would loop the watcher onto itself. Everything else passes. The filter is permissive. The fine doc-worthiness judgment runs later in the cycle.

• How to run the wiki-watcher — the task-oriented walkthrough.
• Antigravity limitations — why the scheduling that re-invokes this engine is Claude-first.
• Compatibility — supported hosts.
• Wiki-watcher design — the index-vs-run-config split and the rest of the rationale.