Turn Slack bug reports into Linear issues
Scan channels for bug reports, gather details, dedupe, and file clean Linear issues.
Bug triage automation starts where bugs actually get reported: a Slack message saying "is anyone else seeing this?" This workflow scans your chosen channels on a frequent schedule, recognizes bug reports, gathers the missing details from the reporter, checks for duplicates, and files a clean Linear issue with severity, context and links. The thread gets updated when the fix ships.
What does this workflow do?
On each scan, the agent picks up new bug-shaped messages in the watched channels and steps in. It asks the reporter the questions an engineer would ask: what were you doing, which browser or environment, can you share a screenshot. It checks whether the same bug is already filed in Linear or visible in your error tracking via PostHog, and links the report to the existing issue.
Then it files: a structured Linear issue with reproduction steps, environment, severity, the Slack thread linked, and related PostHog error events or recent GitHub changes attached when they correlate. The reporter gets told the issue number, and when the issue closes, the agent returns to the original thread: "This is fixed in today's release."
How does it work?
- The agent scans the channels you choose. Each scheduled run picks up bug-shaped messages posted since the last one. Ambiguous ones get a quick "want me to file this?" first.
- It completes the report. Missing reproduction steps, environment details and screenshots get requested from the reporter in the thread, conversationally.
- It deduplicates. Against open Linear issues and recent PostHog error events. Existing bugs get the new report linked as another occurrence, which raises priority without adding noise.
- It files and routes. A structured issue in the right Linear team and project, severity proposed from impact and frequency. Your triage lead can approve severity for critical bugs.
- It closes the loop. The reporter learns the issue number immediately and hears back in the original thread when the fix ships.
Why automate this handoff?
The Slack-to-issue-tracker gap eats bugs. Engineers see the message, mean to file it, and the thread scrolls away. Reporters stop reporting when nothing visibly happens. Duplicates pile up because searching Linear from Slack is friction.
The loop-closing matters as much as the filing. When reporters see their reports become issues and hear when fixes ship, they keep reporting, and report quality rises because the agent's follow-up questions teach what a good report contains. The workflow also learns your team's routing: which product areas map to which Linear teams, what your severity levels mean in practice.
Works with
Slack, Linear, GitHub, PostHog, Notion. Scans the channels you choose on a schedule, hourly or more often.
Frequently asked questions
Does it file everything that looks like a complaint?
No. Clear bug reports get filed after details are gathered. Ambiguous messages get a "want me to file this?" prompt, and the agent learns your team's threshold from the answers.
How does deduplication work?
New reports are compared against open Linear issues and recent PostHog error events by symptom, area and environment. Matches get linked as additional occurrences with the new context attached.
Can it set severity on its own?
It proposes severity from impact, frequency and affected customers. Teams that want control require a triage lead's one-tap approval for anything marked critical.
What context gets attached to the issue?
The full Slack thread, reproduction steps, environment, screenshots, related PostHog error events, and recent GitHub changes to the affected area when they correlate.
Does the reporter hear back?
Yes, twice. Immediately with the issue link, and again in the same thread when the issue is resolved. That loop is what keeps people reporting.