Most documentation work is not the writing. It is the part before — reading the diff, finding the design doc, asking the engineer who shipped it what changed for users, and reconciling the new behaviour with the page that was right last quarter.
Dawn is the agent that already lives across the source-of-truth your docs are supposed to describe. Connected repos, PRs, design files, tickets, the existing memory pages — the agent reads them when you ask, drafts from them when you want it to, and tells you when something on the page no longer matches what the code does.
The problem
A documentation page goes stale the moment the engineer who knew the area moves on to something else. The next change to the code happens, the page does not, and a quarter later the docs and the product disagree. The writer is rarely at fault — the system that would catch the drift simply does not exist on most teams.
Dawn is not a magical doc updater, but it is the first agent on most teams that can actually read both sides of the comparison. The page on the docs site, and the code that the page is supposed to describe. That is enough to make a real difference to how doc work feels.
A doc-shaped day
These are the moments writers using Dawn tend to reach for it first.
Hand the PR to Dawn. Ask it to summarise what changed for users, what config or API surface moved, and which pages on the docs site probably need to change. The first draft of the new content comes back grounded in the actual diff and the related tickets, with the page list to update.
Ask the agent to compare the current code against the page. Dawn surfaces the specific examples that no longer match, the options the docs do not mention, and the warnings the docs still carry that the code stopped requiring. A targeted edit beats a quarterly audit.
Ask Dawn to pull a real example from the codebase or to write one against the actual public API. The example sits on real code instead of a fictional version that lints clean but does not run.
Onboarding, integration, migration — the kind of doc whose content lives across repos, designs, and tickets. The agent stitches the picture together for the first draft so you can spend the time on the parts that need a human voice.
A useful habit
The most useful single setup is to wire your docs source repo or wiki into Dawn as a connected source, so the agent can read the existing pages while it reads the code. The "what changed for users?" question turns into "what changed for users that the docs page on /features/X does not yet say?" — which is a much more useful version of the question.
The Dawn pieces docs work leans on
GitHub, GitLab, Azure DevOps, Bitbucket — the agent reads the code the docs are supposed to describe, not a paraphrase of it.
Connected sourcesTone, terminology, the do-not-use list, the "we always show config before code" rule — written once, applied to every draft after.
Memory pagesSketch a page layout, a comparison table, or a sample tutorial as a previewable HTML artifact in the conversation. Useful before committing the structure to the docs site.
HTML artifactsPulling current public guidance on a framework, an HTTP standard, an accessibility rule — with citations rather than memory.
Web search and /web-researchA monthly "what changed since last review and which pages might be affected?" run, posted to the team channel, so the audit happens on time even when the calendar gets crowded.
Scheduled tasksTry it
Draft from a PR
Summarise what changed for users in https://github.com/example/app/pull/482, list the docs pages that probably need to change, and draft the new content for eachStale-doc check
Compare /docs/features/scheduled-tasks against the current code under src/scheduled-tasks/ and tell me what no longer matchesReal example
Write a working code example for the public webhook signature verification flow, using the actual public API in our SDKTone consistency
Read this draft against the voice memory page and call out anything that drifts from the team toneExternal grounding
/web-research current MDN guidance on the View Transitions API and pull the parts our migration guide should citeWhere the human still does the work
A draft from real source-of-truth is not the same as a finished page. The structural choices — what to put first, which examples to keep, what tone fits the audience, what to leave out so the reader can actually find what they came for — are still the writer's call.
Dawn collapses the lookup, the cross-reference, and the first-draft assembly. The judgement that turns a complete piece of information into a useful page stays with the human who knows what the reader is trying to do.
Related reading
The product writeups behind the workflows on this page.
How memory pages give the agent durable context the team would otherwise have to repeat.
Pull docs and wikis into the agent's context as connected sources.
Generate previewable HTML pages and prototypes inside the conversation.
Run a Dawn workflow every morning, every Friday, or every release — without anyone having to remember.
Enter Dawn, connect your tools, and get your first grounded answer in minutes.
Live now. Built for real teams and real systems.