How to connect a Slack bug report to its GitHub issue without losing the reporter

Right-click the Slack message, choose "Create an Issue GitHub," and the bug is filed. That part is genuinely one click, no bot to write or host. What doesn't happen automatically is the part you actually asked about: nothing on the resulting issue records who sent the original message, and nothing tells that person when the issue closes. Both of those have to be added on top, by hand or with a small convention, because GitHub's Slack app was built to move the words, not the identity behind them.

The fix that actually works is a habit, not a setting. Paste the reporter's name and a link to their Slack message into the issue description the moment you file it, and treat the issue's close event as a cue to reply in that original thread yourself. Nothing in the native integration does either step for you. Here's the mechanism underneath both gaps, and where the manual version stops holding up.

What the shortcut actually files

The GitHub app for Slack gives you three ways into the same create-issue dialog: right-click a message and pick "Create an Issue GitHub," run /github open to start from a blank form, or use the global lightning-bolt shortcut. All three drop you into a dialog that pre-fills a title, lets you pick the repo, and adds labels, an assignee, or a milestone before you submit. Coming from a message specifically, the words get copied straight into the description, and Slack attaches a link back to the source conversation without you doing anything else. (Turning a Slack message into a GitHub issue without a custom bot walks through all three entry points if you haven't set the shortcut up yet.)

That link back is the part worth noticing. It means the issue always carries a path from GitHub back to the exact Slack message it came from. What it doesn't carry is a path forward, anything that says who wrote that message, or that pings them again once the issue is done. The issue's author field gets set to whoever ran the shortcut and is signed in to GitHub, which is almost never the customer.

The reporter's name has to be typed in, every time

If the same person who triages Slack also files the issue and remembers every reporter by name, this is invisible for a while. It stops being invisible the moment two things happen at once: more than one person is filing issues from that channel, and someone months later needs to answer "who actually hit this" without re-reading the whole thread.

The convention that holds up without any code is a one-line rule: the first line of every issue description reads Reported by <name>, link: <Slack permalink>, typed in by whoever runs the shortcut, before they click submit. A Slack permalink is a real, stable thing to paste: Slack's own API docs describe it as a link built from the channel and the message's timestamp, and copying one from the message's "More actions" menu takes two clicks. That link outlives the thread scrolling out of view, which the auto-attached conversation link inside the shortcut's dialog does not reliably survive on its own if the channel gets archived or renamed later.

This closes the "who asked" question for a single issue. It does nothing for the second half of what you're actually trying to do, which is get back to that person once the bug is fixed.

Closing the loop: what /github subscribe actually posts, and what it doesn't

GitHub's Slack app also has a /github subscribe owner/repo issues command that turns on notifications for opened and closed issues in that repo, posted straight into the channel you ran it in. Close an issue on GitHub, and a card appears in Slack showing the issue's current status, title, and labels, threaded under the original notification for that issue.

That is a real notification, and it is not the same thing as telling the reporter. It posts to the whole channel, not to the person named in the description you typed in step one. If the bug was reported by one gym owner in a channel where forty other people also sit, all forty see "issue closed," and the one who actually hit the bug still has to notice it in the noise, or somebody has to go read the closed issue's description, find the name typed into the first line, and reply to that specific person's original message by hand. GitHub's own subscribe feature was built to keep an engineering channel current on repo activity, not to route a resolution back to a single customer.

A composite example: three reports, one bug, at Kettlecrew

Kettlecrew is a composite, not a real customer, built to walk through how this convention fails once volume picks up. Picture a class-booking software vendor for boutique gyms, where Yannick Ferland is the only backend engineer who regularly reads the support channel gym owners use to flag bugs directly. For most of a year, the flow above worked exactly as described: right-click, file, paste the reporter's name and permalink, done.

Then a waitlist bug showed up three times in ten days, in three different phrasings:

Support, message 1: "A member on our 6am spin waitlist got auto-promoted twice, now she's double-charged."

Support, message 2: "Two people jumped the line on our Tuesday HIIT waitlist this week. Bug or is someone gaming it?"

Support, message 3: "Waitlist promoted the wrong person again, third time this month, owners are asking questions."

Yannick filed all three as separate issues, because none of the wording overlapped enough for a search to catch it, and he was in the shortcut's dialog for each one individually rather than looking across them. Each got the reporter's name and permalink typed in correctly. When the actual fix shipped, a race condition in how waitlist promotions got queued, he closed the canonical issue, /github subscribe posted the closure to the engineering channel, and he told the one owner whose issue he happened to be looking at. "I found out from the third owner that it was still happening for two of the others," Yannick said. "The information to tell all three was sitting right there in the issue descriptions. I just didn't have a reason to go re-read two closed issues I thought were unrelated."

The convention hadn't failed. It had recorded three separate facts correctly, one at a time, and nothing in it made those facts talk to each other or reach back out once the fix shipped.

Three thresholds this habit doesn't survive

The permalink-and-name habit is genuinely sufficient for a team filing a handful of GitHub issues from Slack each week, where one person can hold the open issues in their head. Three things break it, all at the same volume threshold:

1. Dedupe depends on someone recognizing the phrasing. Nothing compares "double-charged" to "jumped the line" to "wrong person again" unless a human happens to remember all three.
2. The reporter list lives inside separate issue descriptions, not anywhere you can query. Answering "how many customers hit this" means opening every issue and reading it.
3. Telling people back is a step someone has to remember to do, for each name, after the close, with no prompt other than their own memory.

This is the gap Modem is built to close, and it's worth saying upfront that Modem is our own product. Take the recommendation with that in mind. Modem connects to Slack and GitHub directly, groups messages describing the same bug into one topic regardless of phrasing, and keeps every reporter attached to that topic as a real identity rather than a name typed into a description once. When the linked GitHub issue closes, the topic already has the full reporter list on it, so telling them back is a filter, not a memory test. Below the volume where dedupe and follow-up start slipping, the shortcut plus the one-line habit above is the whole system, and it costs nothing to run.

For the GitHub side once the issue exists, triaging the backlog at scale covers the labeling and sweep habits that keep it from rotting. For the follow-up half specifically, notifying customers when their feature ships is the same close-the-loop problem from the other direction.

Set this up before the next report lands

Install the GitHub app for Slack, confirm the message shortcut appears when you right-click a bug report, and run /github subscribe <owner>/<repo> issues in the channel where reports land. Then adopt one rule: the first line of every issue filed this way reads Reported by <name>, link: <permalink>, and closing that issue is the trigger to reply in the original thread, not just to close the tab. That combination gets you real attribution and a real loop closed, for the cost of two habits and zero new infrastructure.