How to connect ReplyRabbit with GitHub workflows

Connect ReplyRabbit to GitHub Issues and a customer bug report in FreeScout becomes a GitHub issue with a developer-friendly title, a tidy summary, labels, an assignee and a link back to the conversation. On the Pro plan an agent creates it in one click; on Team it can be created automatically when triage says engineering work is needed. When the issue is closed, ReplyRabbit can draft the customer follow-up, so the loop from report to fix to "it's fixed" stays inside FreeScout.

What the workflow looks like end to end

• A customer reports something broken. AI Signals (if on) flag it, and the agent opens the ticket.
• The agent clicks to create a GitHub issue. ReplyRabbit writes it for an engineer: what's broken, how to reproduce from the customer's description, priority as a label, and the FreeScout link. The email thread can be added as an issue comment so nobody has to paste it.
• The issue lands in the right repository, chosen by a domain mapping, by AI repository matching, or by the default.
• The FreeScout conversation shows the issue number, state, labels and assignee, and stays in sync.
• ReplyRabbit checks linked issues on a schedule, typically every 5 minutes. When the issue is closed, it can draft the "this is now fixed" reply for the agent to send.

Set up the GitHub connection

1. Create a fine-grained token

   In GitHub, create a fine-grained personal access token limited to the repositories ReplyRabbit should use, with Metadata: read, Contents: read and Issues: read and write. A dedicated bot account gives a cleaner audit trail.

2. Choose GitHub as the mailbox's tracker

   In FreeScout, open the mailbox, choose Settings, then ReplyRabbit. In Integrations, set the issue tracker to GitHub Issues. A mailbox uses one tracker at a time.

3. Paste the token and load repositories

   Paste the token, click to load repositories, and pick the default repository for new issues.

4. Set labels and routing

   Choose the labels ReplyRabbit may apply, map its priority levels to labels (GitHub has no native priority field), set a default assignee, and add domain mappings if certain customers always belong to certain repositories.

5. Save and create a test issue

   Save, open a conversation that describes a bug, and create an issue. Check the title and summary in GitHub before rolling it out.

Manual on Pro, automatic on Team

With manual creation, the agent reviews the generated title, summary, labels and repository before the issue exists. That's the right default for most teams.

With Auto-submit issues on the Team plan, ReplyRabbit creates the issue as soon as triage decides the conversation needs engineering. Turn on the Review notice so a FreeScout note tells agents the issue was created automatically and should be checked. Automatic creation is best for mailboxes where most bug reports are real and the cost of a duplicate issue is low.

Telling the team and closing the loop

Add a Slack incoming webhook in the same Integrations section and ReplyRabbit posts to the channel when it creates an issue and when a completion draft is ready. For the customer side, enable Auto Draft on Done; if your team uses close reasons, restrict completion drafts to issues closed as completed so "not planned" closures don't trigger a "fixed" reply.

Keeping customer data sensible

ReplyRabbit sends GitHub the content needed for the handoff: relevant customer context, the generated summary, labels, assignee and the conversation link. If a repository shouldn't receive customer details, don't route to it, or keep GitHub disabled on that mailbox. The full reference, including the troubleshooting table, is in GitHub Issues integration. The other trackers are covered in Linear integration, and notifications in Slack integration. General setup is in How to set up ReplyRabbit, and Troubleshooting ReplyRabbit covers issues that don't get created.