Support replies already waiting when you sit down
Lenny’s same early-access note: auto-replying to support emails, which he said saves him hours. Drafts in his voice; he stays on the send button.
Customer Support·Moderate·0 saves
Setup 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.
How it runs
5 steps. Do them in order.
- 01In Grok Bot, create a bot named **Scribe** and connect GitHub.
- 02Paste the reconstructed prompt below in as its standing instructions, then tell it the one job: help-center updater.
- 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.
- 04Run it on demand; it acts once you approve each step.
- 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.
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 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