How to turn a Slack message into a GitHub issue without a custom bot
You don't need to build anything. GitHub's own Slack app ships a message shortcut, right-click a message and choose "Create an Issue GitHub", that opens a pre-filled issue dialog with the message text dropped into the description and a link back to the Slack conversation added automatically. It also remembers the last repo used in that channel, so repeat use in the same channel doesn't require re-picking a repo each time. That's the whole mechanism for the common case, and most teams that reach for a custom bot haven't checked whether the official integration already covers it.
Install the GitHub app for Slack, sign in with /github signin, and the shortcut is live in any channel or DM the app has been added to. No webhook server, no OAuth flow you own, no code to redeploy when GitHub changes an API. The tradeoff shows up once you look at who the issue says filed it, and that's where most teams' actual problem starts.
“we need SSO before rollout”
“any update on single sign-on?”
“SSO came up twice on this call”
Linear issue, quotes attached
insight report in NotionThe three ways to create the issue, and what each one keeps
GitHub's Slack integration gives you three entry points, and they all end at the same create-issue dialog:
- Message shortcut: right-click any message, pick "Create an Issue GitHub." This is the one worth defaulting to, because it's the only path that starts from a specific message instead of a blank form.
/github open: types the create-issue flow into the chat box from scratch. Useful in a DM where there's no message to right-click yet, but you're typing the description by hand.- Global shortcut: the lightning-bolt menu, same dialog, no message context at all.
Whichever door you use, the dialog fills in title and repo suggestions, lets you set labels, assignees, and a milestone before submitting, and requires you to be signed in with access to the target repo. None of the three requires a line of code. If your current setup involves a webhook receiver that parses Slack's event payload and calls the GitHub REST API to open an issue, that's likely solving a problem the shortcut already solves for free.
Where it actually breaks: the issue's author isn't the customer
The gap is in the author field. It gets set to whoever ran the shortcut and is signed in to GitHub, not whoever wrote the original Slack message. The message text and a link to the Slack thread land in the description, so the words survive, but "who reported this" only survives if a human types the requester's name into the description by hand, every time, and doesn't forget.
That's fine for a five-person team where the engineer who triages Slack also remembers who said what. It stops being fine once a few things happen at once:
- More than one or two people are creating issues from Slack, so nobody has full context on who's asking across the whole channel.
- The same complaint shows up from three different customers in three different messages, and nothing dedupes them, so it becomes three GitHub issues that all say "reported via Slack" with three different unlinked threads.
- Someone needs to answer "which accounts hit this" months later, after the original message has scrolled out of search results, and the issue body just says a name that may or may not still mean anything to the person reading it.
Fanout Health hits this at their support handoff
At Fanout Health, a scheduling-software vendor for physical therapy clinics, support runs in a shared Slack channel where the clinic ops team drops anything a customer flags. Grant Okwuosa leads the platform team there, and for the first year, engineers used the GitHub shortcut directly on those messages.
It worked until a scheduling-conflict bug got reported by three different clinics inside two weeks, phrased three different ways:
Support, message 1: "Riverside Physical Therapy says double-booking still happens when two therapists share a room."
Support, message 2: "Ortho Plus is seeing the same room-conflict thing from last month, they're getting annoyed."
Support, message 3: "Anyone looked at why room booking lets two appointments overlap? Client asked again today."
Three engineers, three shortcuts, three GitHub issues, none of them linked to each other. Grant found out it was the same bug when a fourth clinic mentioned it on a call and he searched GitHub for "double-book" and got three hits. "The bug got fixed in under a day once we actually looked at it," Grant said. "Finding out it was one bug and not three took longer than fixing it."
What Fanout was missing wasn't the ability to create an issue. It was something sitting upstream of GitHub that recognized "double-booking," "room-conflict thing," and "room booking lets two appointments overlap" as the same topic, and could say which three named clinics had asked, before any issue got filed.
The ceiling on the manual shortcut
The shortcut, and the dialog behind it, work well for a team that opens a few GitHub issues a week from Slack and doesn't need to answer "how many customers hit this" without re-reading the channel. Past that point, three things are true at once and none of them get fixed by a better shortcut:
- Dedupe depends entirely on whoever's creating the issue remembering they've seen the phrasing before.
- The requester's account, not just their name, has to be typed in manually if it needs to survive past the initial description.
- Nobody has a single count of how many people are actually asking for the same thing, because that count would require someone to go read every open issue's description and cross-reference it against the original Slack thread.
That's the point where we'd point you at Modem. Modem connects to Slack and GitHub directly: it reads messages and issues as they come in, groups the ones describing the same underlying problem into one topic with a count of how many people asked, and when a topic crosses your threshold it files the GitHub issue itself, with the requester list and quotes attached, not a name typed once and left to go stale. Existing GitHub issues get pulled in as feedback too, so a bug reported first on GitHub and again in Slack lands in the same topic instead of two disconnected records. Full disclosure, Modem is ours, so read that recommendation with the appropriate skepticism. What it actually closes here is narrow: it's the dedupe and requester-tracking layer that "create an issue from a message" was never built to be.
Below that volume, the shortcut genuinely is the whole answer, and a custom bot would just be code to maintain for a problem three clicks already solve.
What to change before the next handoff
Install github.com/integrations/slack in your support or bug-report channel, run /github signin, and confirm the message shortcut shows up when you right-click a report. Add one house rule: whoever files the issue pastes the requester's name and company into the first line of the description, not just the auto-attached Slack link. That single habit is what keeps "who asked" from depending on someone's memory once the thread scrolls away. For the GitHub-side half of this problem, triaging the issues once they land and keeping the Slack channel itself from turning into noise are the next two things worth getting right.
