Close the loop between Front tickets and Linear bug fixes

Build me an app my support team opens every morning to run the loop between our Front shared inbox and engineering in Linear. Today nobody can answer two questions: which customers are blocked on a bug right now, and which of those bugs have already shipped without anyone telling the customer. The app has to answer both, because Front does not know the state of an engineering ticket and Linear does not know who asked for it.

The main view is a board called Waiting on engineering. Load it from Front using List Tagged Conversations for the tags we use for bugs and escalations, and Search Conversations for a configurable query so teams that tag inconsistently can still fill the board. Let me pick which tags, inboxes, and search query feed it in a settings panel, using List Tags and List Inboxes to populate the pickers. Each row shows the customer name and email from the conversation recipient, the subject, the inbox, the Front assignee, how long the customer has been waiting for an answer, and the linked Linear issue with its live state. Sort the board by longest waiting first by default.

Define the waiting clock carefully, because it is the number the whole board is ranked on. It is the time since the customer's most recent inbound message that has not been answered by an outbound reply from us. Work it out from List Conversation Messages by walking the thread and finding the last inbound message with no outbound message after it. Do not use the conversation creation date and do not use the age of the Linear issue. Show it as a human duration such as 6d 4h, and color rows that have crossed a threshold I can configure.

Clicking a row opens a thread panel on the right, powered by Get Conversation for the header details, List Conversation Messages for the customer conversation in order, and List Conversation Comments for the internal notes my team left. This is what someone reads before deciding what to do with the row, so show the full message bodies, not snippets.

For the linked ticket column, read Linear live rather than trusting anything cached. When a row has a mapped issue, call Get Issue to show the identifier, title, assignee, and current workflow state, and link straight through to Linear. Rows with no mapped issue show a File to engineering button instead.

File to engineering kicks off a background agent on that row. It reads the full thread with Get Conversation, List Conversation Messages, and List Conversation Comments. Then, before creating anything, it searches Linear with Search Issues and narrows with List Issues to check whether this bug is already filed. If it finds a genuine match it does not create a second ticket: it links the conversation to the existing issue, writes back into the app which issue it matched and why, and shows me that in the row. Only when there is no match does it call Create Issue in the configured Linear team, with a title written from the actual symptom, a description that includes verbatim customer quotes in a quoted block, the reproduction steps as the customer described them, any environment or account details found in the thread, and a link back to the Front conversation. After the ticket exists it calls Add Comment on the Front thread with the issue identifier and link so the internal note is visible to the rest of the team, and Add Tags to Conversation to stamp a configurable filed-to-engineering tag so nobody double files. Show the agent's progress on the row while it runs and refresh the row when it finishes.

Keep the conversation to issue mapping inside the app, not implied by tags. Store the Front conversation id, the Linear issue id and identifier, who filed it, when it was filed, whether the customer has been told the fix shipped, and the last known issue state. This is what makes links survive when tags get edited, when a conversation is archived, or when someone reassigns the thread. Let a user link or unlink an issue by hand from any row, and record manual links the same way.

The second view is Shipped, customers waiting, and this is the part no tool does today. Walk every mapping in the app, read each issue with Get Issue, and surface the issues whose workflow state has moved to a completed or done state. Group by issue, not by conversation. Under each shipped issue, list every Front conversation still linked to it that has not been marked as told yet, since one bug is usually reported by several customers, and show each of those customers with their waiting time. An issue with five people still waiting should read clearly as five people, not five separate rows scattered around the app.

On each shipped issue there is a Draft the good news button that kicks off a background agent. For every waiting conversation under that issue, it reads the thread again with List Conversation Messages so the wording matches what that specific person reported, then writes one personalized reply: what they reported, in their words, that it is now fixed, and anything they need to do such as refreshing or updating. Each draft is saved into the app in a pending review state, attached to its conversation.

Drafts land in a review queue, never in a customer inbox. A person opens a draft, edits the text freely, and only then clicks Send reply, which calls Reply to Conversation on that thread. Sending is one conversation at a time and always requires that explicit click, with no send all button and no automatic or scheduled sending anywhere in the app. After a reply sends, mark the mapping as told, stamp the conversation with a configurable fix-shipped tag using Add Tags to Conversation, and drop the row out of the waiting list. Anyone can also dismiss a draft without sending.

Give a lead a little more control on the board: reassign a row to another teammate with Assign Conversation, using List Teammates to populate the picker, and close out a row once the customer has been told, which marks it handled in the app and can optionally archive the Front conversation with Update Conversation. Add a filter for my own conversations so an individual agent can work just their queue, plus filters by inbox, by tag, and by whether a ticket is linked yet.

A few rules to hold onto. This is not a themes or feedback clustering board, it is a per-customer accountability board, so never roll conversations up into topics. Rank everything by customer wait time rather than issue age. Front search is expensive against the rate limit, so load the board in one pass, cache it for the session, and give me a refresh button rather than polling. And no customer ever receives anything the app generated without a human reading it and clicking send.