bots.new_
Sign in
USE CASECustomer SupportModerate

“The docs update themselves the moment a PR merges”

Damon’s Intercom + GitHub bot watches every merged PR, decides whether a help-center article needs updating, then drafts and publishes it. 82 likes / 11.4K views.

Grok·0.0·0 saves·25 uses·via @damonchen·Tweet by @damonchen
Open @damonchen on X

How it runs

5 steps. Do them in order.

  1. 01In Grok Bot, create a bot named **Scribe** and connect GitHub.
  2. 02Paste the reconstructed prompt below in as its standing instructions, then tell it the one job: help-center updater.
  3. 03Give it the context it needs — the accounts, files, and rules specific to your setup — so it can hold the job the way the original build did.
  4. 04Run it on demand; it acts once you approve each step.
  5. 05Watch the first few runs, correct anything off, then let it hold the job. Adapt the connected tools to match your own stack.

What you get

Treating merged PRs as the source of truth for documentation flips the usual order, where docs lag behind ship dates by weeks. The bot decides per PR whether an article needs updating, drafts from the actual diff, and only started publishing on its own after five straight approved drafts proved it could be trusted.

Prompt

Copy it. Change the names. Keep the job.

Prompt
Role: Help-center writer tied to GitHub. PRs are the source of truth. Intercom is the surface.

Mission: On every merged PR, decide whether a help-center article needs an update. Draft the change from the PR. Publish only after the first five drafts are approved; after that, still skip anything that invents behavior.

Tools: GitHub, Intercom (or the help center I connect). Read the PR diff and the existing article before you write.

What good looks like:
- Per merged PR: update / no-update / new article, with a one-line reason.
- Drafts quote the actual API/behavior from the PR. Existing article linked.
- First five publishes wait for my yes. A log of what went live.

Never, without asking: publish to Intercom until those first five drafts are approved. Never invent API behavior that is not in the PR. Never delete an article.

Stop if the PR and the current article contradict and you cannot tell which is shipping — ask.
Use withGrok

via @damonchen · Tweet by @damonchen

Tips

  • ·Reconstructed from @damonchen's published Grok Bot build. Adapt the connected accounts and context to your own stack — the prompt is a Curator reconstruction, not the author's original text.
  • ·adhoc
  • ·acts-with-approval

Related setups

Same category. Different job.

More in Customer Support →

An Instagram bug report that routes itself to QA

Dan Peguine's Grok Bot watches his Instagram inbox. A website-bug complaint got routed to a QA bot in the Ship channel (with his engineer bot 'David'); QA tested the funnel, found nothing, and had a Writer bot reply — and a real bug would have become David's fix and a PR.

Customer Support·Advanced·0 saves
Setup

Reply by text, and it works the helpdesk for you

Jesse Hanley’s thread is not a one-liner dump: he already runs a support bot against Bento Chat / helpdesk. It sweeps a few times a day, summarises what is assigned or escalated, and he texts back what to do — then it hits the admin MCP. “This is what I’ve done and it’s fantastic.”

Customer Support·Moderate·0 saves
Setup

One ticket, a root-caused PR, and a reply by morning

Wilson (euboid) built the loop after asking whether Grok Bot could debug tickets, open a PR, and draft a reply. Incoming ticket → agent reads Fern docs, codebase, Axiom logs → bug gets RCA + PR + Linear, feature request hits the board, customer reply is drafted in his voice.

Customer Support·Moderate·0 saves
Setup