Turn Re:amaze bug reports into Linear issues, not duplicates

Every two hours, review my recent Re:amaze support conversations, work out which ones describe a genuine product bug, and get those in front of engineering in Linear without ever filing a duplicate. Run this on a cron schedule every two hours.

Start with the Re:amaze List Conversations operation to pull conversations created or updated since the last run. Cover the last two hours with a little overlap so nothing slips through between runs. For each candidate conversation, use List Messages scoped to that single conversation to read the full back and forth, because the opening message often lacks the detail that reveals whether something is actually broken.

Then judge each conversation. A genuine product defect means the product is behaving incorrectly, erroring, or failing to do what it promises. Do not escalate how-to questions, feature requests, billing and refund issues, shipping or delivery complaints, or password and account access problems that are not caused by a defect. If a conversation is genuinely ambiguous, leave it alone rather than filing a speculative bug. Skip conversations that already carry the escalated tag so repeat runs do not reprocess them.

Before creating anything in Linear, search for an existing issue. This step is the point of the workflow, so never skip it. Use the Linear Search Issues operation with the distinctive terms from the report, such as the exact error text, the affected feature, and the page or screen name. Try more than one phrasing, since the customer's wording and the engineer's wording rarely match. Judge whether a result covers the same underlying problem rather than requiring identical words.

If a matching issue already exists, do not create a second one. Use Add Comment to Issue instead, recording that another customer has just hit this, the date, a link to the Re:amaze conversation, what the customer said in their own words, and the running impact such as how many separate reports have now come in.

If the bug is new, use Create Issue. Give it a specific title naming the thing that is broken, for example "Discount codes rejected at checkout for UK customers", never something vague like "Customer reports a bug". In the description include reproduction steps drawn from the customer's own words with the relevant lines quoted directly, what they expected compared with what actually happened, any environment details they mentioned such as browser, device, plan, or order number, and a link back to the Re:amaze conversation. Set priority from how many customers have hit it and how severe it is: Urgent for data loss, broken checkout or payments, or an outage hitting many customers; High for a core feature broken with no workaround, or several separate reports; Normal for a single report with a workaround; Low for cosmetic problems.

Close the loop on the support side. Post the Linear issue link and a one line summary back onto the Re:amaze conversation using Create Message as an internal note, so it is visible to the support team but never sent to the customer. Then use Update Conversation to add an escalated tag to that conversation.

Finally, send a short Slack message with the Slack Bot Send a Message operation to the on-call engineering channel for each escalation. Keep it to a few lines: what is broken, whether this is a new issue or another report of a known one, the priority, and the Linear link. If nothing qualified as a bug in a given run, stay silent rather than posting an empty update.