How to Automate Documentation Updates in Guru After a Release
If you want to know how fast a software company is moving, look at the gap between their deployment pipeline and their knowledge base.
A team ships a release on Tuesday. The code is merged, the automated tests pass, and the deployment is seamless. But on Thursday, a support rep fields a ticket about a changed feature, searches Guru, and finds a Card that describes a UI from three versions ago. They ping an engineer in Slack. The engineer, deep into the next sprint, types out a hasty explanation.
The code shipped instantly. The documentation is still waiting for someone to manually extract what happened, rewrite it, find the right Guru Card, and click update.
This is documentation drift. It happens because the mechanical process of writing about software has not kept pace with the mechanical process of shipping it. We have automated how we build and deploy, with elite teams shipping on demand, but we still rely on human memory to update the knowledge base. The bigger the release, the worse the lag.
The answer is to connect the two systems. You automate documentation updates in Guru by treating documentation as a byproduct of the engineering workflow, generating structured output from code changes, and pushing it to Guru programmatically.
The Gap Between Shipping and Telling
The problem isn't that teams don't care about documentation. It's that the math doesn't work.
A team shipping weekly averages multiple user-facing changes per week. Each change affects several help articles or internal knowledge base entries. That means dozens of articles might need updates every sprint. The time allocated for this is usually zero hours explicitly, squeezed into the margins of other work.
When documentation trails deployment, the operational costs are high. Support teams field preventable tickets. Poor documentation practices cost mid-sized engineering teams significantly in lost productivity. Developers spend hours compensating for missing or outdated information. When users can't find answers, they open tickets. Effective self-service documentation is the primary driver of ticket deflection, yet we routinely let it fall out of sync.
The instinct is to force engineers to write release notes before they merge a pull request. This rarely works. Engineers will do the bare minimum to satisfy the requirement, resulting in notes that say "fixed bug." The structural problem with manual release notes is not effort — it's incentives.
How the Pipeline Actually Connects
Automating this process means connecting a documentation generation system to your release pipeline.
It starts with the engineering artifacts you already have: Git commits, Jira tickets, and pull requests. When a release is tagged, a system reads these artifacts and generates structured output — changelogs, feature descriptions, deprecation notices. This approach, often called Docs as Code, brings software development practices to documentation.
This output is then pushed into Guru using its REST API. The system can create new Cards or update existing ones based on defined triggers, like version tags or release labels.
You set up a workflow where a merged pull request triggers a GitHub Action. The action generates the documentation based on standards like Conventional Commits, formats it, and makes an API call to Guru to update the relevant Card.
The Part Everyone Gets Wrong
Guru's strength is human-curated knowledge. It relies on verification workflows to ensure information is accurate and trusted.
This means you cannot just spray AI-generated content into Guru and walk away. If you automatically overwrite verified Cards with unreviewed generated content, you destroy the trust in your knowledge base. Someone still needs to validate that the right Cards were updated, that the tone matches your standards, and that nothing broke.
Mature teams handle this by using automation to generate the first draft. They push it to Guru as an unverified Card or a draft. Then, it is routed to a subject matter expert or a technical writer for final review before publishing. Maintaining a human-in-the-loop is critical for ensuring the quality of AI-generated content. The system handles the extraction and formatting; the human handles the governance.
The Operational Shift
When you automate the mechanical parts of documentation, the operational dynamic changes.
Support teams get updates faster and more consistently. They stop answering questions with outdated information. Engineers stop getting interrupted days after a release to explain what they built.
Technical writers stop acting as archaeologists, digging through Slack threads to figure out what happened last week. They become editors, refining the narrative and improving high-impact documentation. The knowledge base stays closer to the actual state of the product.
Automation handles the repetitive extraction work. It does not replace the need for someone who understands your product and your users. Guru is only as useful as the structure and context humans put into it.
Doc Holiday generates release documentation directly from engineering workflows — changelogs, feature descriptions, API updates — and can push that content into platforms like Guru programmatically. It gives teams a structured way to validate and manage those updates at scale, so your knowledge base stays current without the manual scramble after every release.
