Most teams already write down what changed and why, every time they merge a pull request. The title, the description, the diff itself, that is a documentation brief you did not have to ask anyone to write. The only missing piece is a pipeline that reads it and turns it into an article.
Here is what that pipeline actually looks like, end to end, from a merged PR to a published article.
Direct answer
To turn GitHub pull requests into help articles, connect your repository, verify and de-duplicate the merge webhook, classify whether the change is customer-facing, retrieve related existing articles for context, draft the update from the diff and PR description, and route the draft to a human for one-click approval before it publishes. DocsKoala runs this exact pipeline: it watches your merged PRs and turns qualifying ones into review-ready drafts automatically.
The pipeline, step by step
- Webhook received: a GitHub PR-merged event arrives, gets its signature verified, and is de-duplicated so retries don't create doubles.
- Diff normalized: the raw diff is turned into a change set the model can reason about, alongside the PR title and description.
- Classified: a fast model decides whether the change is customer-facing at all. Internal refactors and test-only PRs stop here.
- Related articles retrieved: for customer-facing changes, a vector search pulls the existing articles most likely affected, so the draft updates the right one instead of writing a duplicate.
- Drafted: a stronger model writes the new article or the update, grounded in the diff, not a general prompt.
- Reviewed: the draft lands in the Review Inbox as pending. A human approves, edits, or dismisses it.
Why the draft has to be grounded in the diff
A model asked to "write docs about this feature" with no diff will happily invent behavior the product does not have. Feeding it the actual code change, not just a description of it, is what keeps the draft describing what shipped instead of what sounded plausible.
This is also why classification runs first: only customer-facing changes are worth drafting for. A change to internal tooling or a refactor with no visible behavior difference should never reach a human's review queue.
What still needs a human
The pipeline removes the blank-page problem and the remembering-to-update-it problem. It does not remove editorial judgment. Voice, tone, anything that depends on business context a diff cannot carry, and the final decision to publish stay with a person.
Frequently asked questions
Does every merged PR generate a draft?
No. A fast classification step filters for customer-facing changes first. Internal refactors, test-only changes, and anything with no visible product impact never reach a draft.
Do I need to write prompts for each PR?
No. The pipeline is triggered automatically by the merge webhook and drafts from the diff and PR description. There is no manual prompting per change.
What happens if the classifier gets it wrong?
The Review Inbox is the safety net. A dismissed draft costs nothing, and any customer-facing change that slipped through un-drafted can still be surfaced manually. Nothing publishes without a human seeing it first.
Conclusion
- Merged PRs already carry most of what a help article needs.
- A working pipeline classifies, retrieves context, drafts, and stops at a human for approval.
- Grounding the draft in the real diff is what keeps it accurate.
- See how DocsKoala works for the full technical flow, or check pricing to start a trial.