# Turn GitHub releases into Guru knowledge updates for Support and Sales

> The moment engineering ships a release on GitHub, publish a plain-English recap to Guru, alert Support and Sales, and post a TL;DR in Slack.

- Workflow type: agent
- Services: GitHub, Guru, Slack Bot
- Categories: Engineering, Product
- Published: 2026-07-02

## What it does

- Watches your GitHub repository and fires the moment engineering publishes a new release.
- Rewrites the raw release notes into a customer-facing summary: what shipped, who is affected, and what to say to customers.
- Publishes the recap to Guru by appending to your existing Product Updates card, or creates a new one in the right collection with the right verifier.
- Sends a Guru Knowledge Alert to the Support and Sales groups so the update actually lands in their inbox, and posts a two-line TL;DR with a link to the card in your #product-updates Slack channel.

## What you'll need

- A GitHub account connected to the repository you release from.
- A Guru account with permission to create and update cards, and knowledge alerts turned on for your Support and Sales groups.
- A Slack workspace with a channel where you want the TL;DR posted (for example, #product-updates).

## Prompt

Build an agent workflow that turns every new GitHub release into a customer-facing knowledge update in Guru, alerts Support and Sales, and posts a TL;DR in Slack.

Trigger: a GitHub webhook on the release event with action "published". Do not use a poll or a cron. The webhook payload gives you the repository, the release id, the tag name, whether it is a draft or prerelease, and the release body.

Filter first. Skip the run entirely if the release is a draft, a prerelease, or the tag name (or release name) contains an internal-only marker like "internal", "internal-only", or "do-not-ship". Only real, customer-facing published releases should continue.

Step 1: Pull the full release from GitHub using Get a Release (by the release id from the webhook payload). Capture the tag name, the release name, the published_at timestamp, the release body (raw Markdown release notes), and the html_url so we can link back to it.

Step 2: Rewrite the raw release notes into a customer-facing summary. Structure it as three short sections: "What shipped" (plain English, one sentence per change, no engineering jargon), "Who is affected" (which customer segments, plans, or personas care), and "What to say to customers" (2 to 4 ready-to-paste talking points Support and Sales can use verbatim). Keep it tight; this is not a changelog, it is enablement copy. Include the tag name and a link back to the GitHub release at the bottom for reference.

Step 3: Find the right Guru card. Use Search Cards in Guru to look for an existing "Product Updates" card (or a feature-specific card if the release touches a single feature area). If a good match exists, use Update Card to append the new release as a new section at the top of the card body, keeping older release sections underneath. If nothing matches, use Create Card to create a new card in the Product Updates collection, assign the right verifier group (Product or the release owner), and set a reasonable verification interval so it stays fresh.

Step 4: Send a Guru Knowledge Alert with Create Announcement, targeting the Support and Sales groups, pointing at the card that was just created or updated. The announcement message should be one sentence: what shipped and why it matters to customers. This is what makes the update actually land in people's Guru inbox instead of quietly sitting in a card.

Step 5: Post a TL;DR in Slack. Use Slack Bot Send a Message to post to #product-updates (make the channel configurable). The message should be two lines: the customer-facing headline, then a link to the Guru card. Keep it scannable.

Idempotency: if the same release id fires the webhook twice, do not double-post. Check the Guru card body for the tag name before appending, and do not send a second announcement or Slack message for a release already published.

Integrations to use: GitHub (Get a Release), Guru (Search Cards, Create Card, Update Card, Create Announcement), Slack Bot (Send a Message).

## How to customize

- Change which releases count. Skip drafts, prereleases, or anything tagged internal-only, or narrow to a specific repo or tag pattern.
- Pick the audience. Choose which Guru groups get the Knowledge Alert and which Slack channel gets the TL;DR.
- Reshape the recap. Tune the tone, add a customer-facing headline, or include a section on known issues and workarounds.
- Route by area. Point mobile releases at one Guru card and backend releases at another so knowledge stays organized.

## FAQ

### Will it run for every GitHub release, including drafts and prereleases?

No. Drafts, prereleases, and anything tagged as internal-only are skipped by default. Only real, published releases become customer-facing updates.

### What happens if a Product Updates card already exists in Guru?

The agent finds the existing card and appends the new release section at the top. If no matching card exists, it creates one in the collection you choose and assigns the right verifier.

### Do Support and Sales actually get notified, or does the card just sit in Guru?

Both. The agent sends a Guru Knowledge Alert to the Support and Sales groups so it shows up in their Guru inbox, and posts a short TL;DR with a link to the card in a Slack channel of your choice.

### Can I use this if my repository is private?

Yes. As long as your connected GitHub account has access to the repository, the agent can read the release and its notes.

### How do I stop a specific release from being published?

Tag the release as a prerelease, leave it as a draft, or add an internal-only marker to the tag. Any of those will skip the workflow.

Use this prompt in General Input: https://www.generalinput.com/prompts/turn-github-releases-into-guru-knowledge-updates-for-support-and-sales