Automating cross-repo documentation with GitHub Agentic Workflows

The Aspire team automated documentation drafts across separate code and documentation repositories while keeping engineers responsible for approval. Its GitHub case study describes a workflow triggered by a merged code change. Fixed rules first select the documentation branch. An agent then reads the change and linked issues, decides whether documentation is needed, and drafts an update. A separate process with restricted permissions creates the draft pull request.

For May 3 through June 2, the team reports 396 workflow runs and 82 documentation pull requests, all subsequently merged with human review. The median interval from product merge to documentation merge was 44.8 hours. This measures the completed review workflow, rather than the agent's drafting speed.

“Here’s what that bought us, in numbers pulled straight out of GitHub: for Aspire 13.3 and 13.4, 82 feature-docs pull requests merged at a median of 44.8 hours after the product pull request , every one of them reviewed by the engineer who shipped the feature.”

github

“Critically, the agent doesn’t write to GitHub directly . It emits intent (a JSON blob describing the pull requests, issues, and comments it wants to create), and a separate, narrowly scoped job (the safe-outputs handler ) materializes that intent against a per-workflow GitHub app.”

github

“The agent gets a GitHub App token whose installation is scoped to exactly two repositories —the product repo and the docs repo—and nothing else in the org is reachable.”

github

“396 runs → 82 pull requests is not a defect. The workflow runs on every merged pull request; most of them are internal refactors, test fixes, or dependency bumps with no user-facing surface.”

github

“The agent’s “is this docs-worthy?” gate was too generous in the first version. It drafted pull requests for changes that were genuinely internal, such as a CI tweak or a logging refactor.”

github