Why Does a Bug Reported in Slack Need to Become a GitHub Issue Before Devin Can Fix It?
Because the Slack thread and the GitHub issue are doing two different jobs. You can @-mention Devin directly in a Slack channel and get a real answer back in the thread, Cognition's own Slack integration supports exactly that. But answering a question in a thread and fixing a bug in a repo are not the same task, and the second one needs things a Slack message doesn't naturally carry: an exact scope, a reference to the code that handles the working case, and a way to know the fix is done. A GitHub issue is where that structure lives by convention. A Slack thread is where it doesn't.
That gap is why teams that route bugs to Devin still stop and write an issue first, even when Devin is one @-mention away in the same channel the bug was reported in.
What @-mentioning Devin in Slack actually gets you
Devin's Slack integration is real and it's useful, so it's worth being precise about what it does. You can tag @Devin in any channel or thread, run /ask-devin for a quick question, or right-click a message and choose "Ask Devin about this." Devin replies in the thread, and you can steer the session with keywords like mute or archive without leaving Slack. There's one requirement buried in the setup docs that trips people up the first time. Your Slack email has to match your app.devin.ai account email, or the integration can't link the session to your account.
None of that is scoping work. It's a chat interface to a Devin session, and the docs are direct about the tradeoff: "Devin may make mistakes. Please double-check responses." That's a fine warning for a quick question. It's a bigger deal when the "response" is a code change touching a repo other people depend on, which is a different weight class than "can you explain what this error means."
What a GitHub issue carries that the thread doesn't
Devin's GitHub integration is built around the repository, not the conversation. Once an org admin connects it through Settings, Devin gets read-and-write access to a specific set of scopes: contents, so it can commit code, pull requests, so it can open them, and issues, so it can file new ones. When it opens a PR, it looks for a repo-specific template first, checking paths like .github/PULL_REQUEST_TEMPLATE/devin_pr_template.md before falling back to a default format. Once the PR exists, "Devin automatically responds to PR comments as long as the session has not been archived," which is what makes review-and-iterate work as a thread of its own, just one anchored to a diff instead of a conversation.
There's no documented mechanism for assigning Devin to an existing GitHub issue and having that trigger a session. The issue scope covers Devin opening issues, not being invoked from one. So the issue isn't a trigger, it's a container. It's the place where the scope, the reference code, and the success criteria get written down before anyone asks Devin to do anything, in the repo where the fix will land, next to the templates and CI checks that already govern every other PR there.
Cognition's own guidance on instructing Devin effectively is specific about why that structure matters: give it the exact scope of what's broken, links to existing code that already handles the adjacent case correctly, and a measurable definition of done, rather than "make sure it works." A Slack thread rarely has all three sitting in one place. It has a customer's plain-language description, maybe a screenshot, and a few follow-up messages scattered across replies. A GitHub issue is where someone has already done the work of turning that into scope, a repro, and a definition of done, because that's the convention every issue in the tracker follows.
Devin answers the category until someone writes the scope down
Watch what changes between the two containers. A customer posts a symptom in your shared Slack channel, teammates react, one asks a clarifying question, and someone confirms further down the thread that other instances hit the same thing. @-mention Devin there and you get a reasonable answer about the general class of bug, because the class is the only thing the thread states cleanly. The version, the affected scope, and the confirming report are all real, and they're scattered across replies and reactions rather than written down as facts of the case.
Now file the same thing as a GitHub issue, and write the pieces Cognition's guidance asks for:
- Scope, naming the narrow behavior that's broken rather than the subsystem it lives in.
- Reference, pointing at the function that already handles the adjacent case correctly, by file and symbol.
- Repro, with the logs or steps attached to the issue itself.
- Done when, written as a condition someone can check against those attachments.
Nothing in that issue is new information. Every piece of it was already in the thread. What changed is that the scope, the reference code, and the definition of done now sit in one place, in the repo where the fix will land, before Devin opens it. Point Devin at that and the session starts from the case instead of the category.
“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 Notion
DevinWhere doing this by hand stops working
Writing one issue by hand from one Slack thread is a ten-minute job, and plenty of teams do exactly that and never feel the need for anything else. It stops working the moment the same bug shows up in more than one place. A bug that gets reported in Slack today and shows up as a support ticket from a different customer next week produces two issues, two Devin sessions, and two PRs solving the same problem, because nothing connects the two reports to each other. The person who filed the first issue has no way of knowing the second one is the same bug until someone notices the diff looks familiar.
That's also where the requester gets lost. The issue captures the bug; it doesn't automatically capture that the customer who first posted, and the people who chimed in to confirm the same symptom, are the ones worth telling when the fix ships. That follow-up either happens because someone remembers to scroll back through the original thread, or it doesn't happen at all.
Once that follow-up is routinely lost, an aggregation layer becomes worth the setup, and Modem is what we build for it. Modem watches the Slack channels, support tools, and GitHub repos a team already uses, matches new reports against existing topics instead of treating each one as new, and can compose the GitHub issue, with the actual customer quotes attached, and hand it to Devin when you ask. Reports of the same symptom cluster into one topic the first time the second one arrives, and the issue that reaches Devin already carries every requester's name so the follow-up can go to all of them instead of whoever happened to file the first ticket. We build Modem and have an obvious stake in that answer. If a bug like this only turns up once a quarter, writing the issue by hand would still be the right call.
Write the issue before you tag anyone
If bugs like this hit your team a few times a year rather than every week, the fix is procedural rather than a tool purchase. The first person to notice a bug in Slack writes it up as a GitHub issue before tagging anyone, using Devin's own instructing guide as the template, scope, reference code, repro, done-condition. For the issue-hygiene half of that habit, our guide to triaging GitHub issues at scale covers the labeling and sweep discipline that keeps a growing issue count from turning into its own backlog. And if the question is less "how do I write the issue" and more "what does Devin need in it," our breakdown of Devin's context requirements goes deeper on that specific list.