# Turn shipped Linear work into Intercom product announcements > A board your product marketer opens on every ship day to turn finished engineering tickets into announcements customers actually read in your Messenger. - Workflow type: app - Services: Intercom, Linear, Slack Bot, General Input Database - Categories: Product, Marketing - Published: 2026-08-24 ## What it does - Shows a three column board: work you shipped but never announced, announcements in draft, and what is live on your Messenger newsfeed right now. - Select one or several shipped tickets, hit Draft the announcement, and a background agent rewrites the engineering write up into a customer facing title, a short body, and a plain line on who benefits. - Every draft lands unpublished, so nothing reaches customers until you edit the copy in the board and press publish, choosing which newsfeed it goes to and who it comes from. - When you publish, the app comments back on the original tickets so engineers see their work shipped, and remembers which tickets are already announced so the same feature never goes out twice. ## What you'll need - An Intercom workspace where you publish product news to the Messenger newsfeed, with at least one newsfeed set up - A Linear workspace, plus a label your team puts on work that customers should hear about - A Slack workspace if you want each draft posted to a team channel for sign off - A teammate in Intercom to send announcements from ## Prompt Build me an app my product marketer opens whenever we ship, to turn finished engineering work into the product announcements customers actually see inside our Intercom Messenger. The whole thing is one board with three columns: shipped work that has never been announced, announcements in draft, and announcements that are live on the newsfeed. Column one, unannounced shipped work. Read completed Linear issues carrying our customer facing label using Linear List Issues, filtered to a completed workflow state and that label, with Search Issues available when I want to narrow by keyword. Show each row with its title, team, the person who worked on it, and when it was completed. Critically, this column must be derived from a stored mapping and not from a date filter alone: hide any issue whose id already appears in the app's record of announced work, so the column stays trustworthy even if someone reopens a ticket, edits its dates, or the same work gets relabelled. Persist that mapping in the app's own storage. One row per link between a Linear issue id and the Intercom news item id it became, plus the issue identifier and title as they were at draft time, the current state of the announcement (drafted or live), who drafted it, who published it, and the timestamps. A single announcement can cover several Linear issues, so the mapping is many issues to one news item. This record is what makes the unannounced column and the never announce twice guarantee work, so write to it as soon as a draft is created, not only at publish time. I select one or several rows in the unannounced column and press a "Draft the announcement" button. That kicks off a background agent inside the app. For each selected issue the agent pulls the full detail with Linear Get Issue, including the description and comments, then rewrites the engineering language into customer facing copy: a short punchy title, a body of two or three sentences a customer would understand, and a plain description of who benefits and what they can now do. If I selected several issues, the agent writes them up as one combined announcement rather than several. The agent then files the result as an unpublished news item using Intercom Create a News Item, authored by an admin, so nothing reaches customers automatically. It writes the mapping rows linking every source Linear issue id to the new news item id, and the drafts column picks it up. Give the agent hard rules on the copy: keep engineering jargon, internal ticket references, issue keys, branch names, and internal system names out of the customer facing text entirely. Write in the words a customer would use for the problem, lead with the benefit rather than the implementation, and never invent capability the issue does not describe. If an issue is too internal to be worth announcing, say so in the draft rather than padding it. Column two, drafts awaiting review. Show each draft's title, body, and who benefits line, all editable inline in the column. Saving an edit writes the change back through Intercom Update a News Item while keeping the item unpublished. Also show which Linear issues the draft came from, with links back to them. When a new draft is created, post it to our team channel for sign off with Slack Bot Send a Message, including the drafted title, the body, and a link into this app so someone can review it. Publishing is always a deliberate human action. When I am happy with a draft I press publish, and the app asks me to choose the newsfeed and the sender before it does anything: populate the newsfeed choices from Intercom List All Newsfeeds and the sender choices from Intercom List All Admins, remembering my last choice as the default. Publishing then flips the item live through Intercom Update a News Item, assigning it to the chosen newsfeed with the chosen sender. Immediately after it goes live, leave a comment back on every originating Linear issue with Linear Add Comment to Issue, saying the work has been announced to customers, quoting the published title, and linking to the announcement, so engineers can see their work shipped. Finally, update the stored mapping to mark those issues as live. Column three, live. Show what is currently on the newsfeed using Intercom List Live Newsfeed Items for the selected newsfeed, newest first, with the title, the sender, and when it went live. Let me switch which newsfeed I am looking at. Where a live item matches a row in the stored mapping, show the Linear issues behind it so I can trace any announcement back to the work that produced it. Make the board fast to work in on a ship day: multi select with checkboxes in the first column, a running count of how much shipped work is still unannounced, and a clear empty state when everything has been announced. If an announcement fails to create or publish, surface the error on the row rather than silently dropping it, and never write a mapping row for work that did not actually get filed. ## How to customize - Change which Linear label counts as customer facing, or widen it to several labels and teams - Set the tone and length the agent writes in, for example one short paragraph versus a fuller changelog entry - Pick the Slack channel that gets the sign off post, or turn the sign off step off entirely - Choose a default newsfeed and default sender so publishing is one click most of the time ## FAQ ### Can anything be announced to customers without me approving it? No. The agent only ever files announcements as unpublished drafts. Nothing appears on your newsfeed until you read the copy in the drafts column and press publish yourself. ### How does the board know a feature was already announced? The app keeps its own record linking each Linear ticket to the announcement it became. The unannounced column hides anything already in that record, so it stays accurate even if someone changes a ticket date or reopens it. ### Will the announcements contain ticket numbers or engineering jargon? No. The agent is told to strip internal ticket references, issue keys, and engineering language, and to write in the words a customer would use. ### Can I announce several tickets as one release note? Yes. Select multiple shipped tickets before drafting and the agent writes them up as a single announcement, then comments back on every ticket it used when you publish. ### Can I still edit the wording before it goes live? Yes. The drafts column is editable in place. You can rewrite the title, the body, and the who benefits line, and your edits save back to the draft announcement in Intercom. Use this prompt in General Input: https://www.generalinput.com/prompts/turn-shipped-linear-work-into-intercom-product-announcements