Documentation decays one merged PR at a time. Each individual PR makes the docs slightly more wrong, and no single moment ever feels like the right time to fix them — so doc updates accumulate as a vague background guilt until a new hire or a customer hits the gap.
Asking every engineer to update docs in the same PR sounds right and fails in practice: doc changes get rubber-stamped along with code review, or skipped under deadline pressure. The work needs its own pipeline with its own reviewer.
A Fleet workflow runs after work ships: it drafts the documentation update from the changed code and existing docs, an independent review step checks it for accuracy against the source, and a maintainer approves before anything lands.
| Step | Kind | What it does |
|---|---|---|
draft |
Document | “Update the affected documentation for the change described in the trigger ticket. Source of truth is the corpus.” Reads docs/**/*.md, src/**/*.ts. |
accuracy |
Review | “Verify every statement against the source files. Flag drift.” |
maintainer-ok |
Approval gate | Pauses the run for a human sign-off; records the approver, timestamp, and note. |
You build this once on the dashboard canvas; your self-hosted Fleet worker pulls the definition and runs it against your repository.
In the dashboard builder, the workflow can be wired to a label trigger — tag a shipped ticket docs and the run starts seeded with that ticket's context — and the output can be a ticket instead of a file: the approved draft becomes a ready-to-review docs issue, assigned and labeled.
Label trigger on shipped work → draft from code + docs corpus → accuracy review → approval. The docs update gets what code gets: an author, a reviewer, and a sign-off — instead of being a checkbox inside someone else's PR.
Teams whose docs live in the same repo as the code (or an adjacent one) and who already know which merges deserve doc updates but never have the slack to write them.
A label-triggered run is seeded with the trigger ticket — its title, body, and references. Combined with corpus globs over the source and docs, the draft step sees both what was supposed to change and what the code now says.
The default output is an approved document artifact, and the builder supports a ticket output — the run files a docs issue containing the approved draft. Direct PR authoring is part of the code-step capability, which sits behind a feature flag, off by default.
One binary. Five minutes. See every agent, coordinate every handoff, and keep a full audit trail of what your fleet did.
