The thing you shipped Tuesday is a launch candidate by Wednesday

A team merges a feature, mentions it in a meeting, maybe writes a note, and then moves on. This reads all three places, works out which of the merged work a customer would actually notice, and writes one launch page per thing: what it is, who it is for, what it still needs before it can go out. On plan day it fills the week’s three launch slots with the best fit, and a person says yes, swap, or drop.

What it does

• Reads every pull request merged in the last four weeks and groups them into things a customer would notice. Internal cleanup is never a launch.
• Reads the team’s own meeting notes and the site’s blog or changelog feed for the same window, so a thing the team talked about and a thing the team wrote about both count.
• Writes one short launch page per candidate in your workspace: what it is, the link, who built it, who it is for, and what is missing (a landing page, a card image, a note).
• A thing a meeting only planned, not built, is an idea, shown apart from the candidates and never launched until there is a pull request or a page behind it.
• Keeps the launch calendar: three slots a week, each with an owner, a day, and a topic. On plan day it proposes the best candidate for each open slot, by who it is for, never by what is already built.
• Takes “launch the CLI”, “swap x for y”, “drop x” and “plan the week” in chat, and moves the pages and the calendar to match.

The reveal

Sunday evening there are three names in next week’s slots, each with a launch page behind it: the Mac app for founders on Monday, the new export for teams on Wednesday, the CLI on Friday. Each page says what is still missing. You read the three, say “launch all” or “swap the export for guest chats”, and the week is planned before anyone is in.

Configuration

• Where the team ships: the GitHub repositories to read.
• Where the team talks: the meeting notes tool, and the address of the site’s blog or changelog feed, if there is one.
• Who you sell to: two or three short persona names, in your words. Each candidate is marked for one, both or unclear.
• The week: how many launches a week (three by default), which days (Monday, Wednesday, Friday), and plan day (Sunday).
• How often: when you ask, or every morning if an available scheduler can run the work and you approve it.

What it doesn’t do

• It doesn’t write the posts. That is what Post Drafter is for.
• It doesn’t post, and it doesn’t build the landing page. It says what is missing and leaves it to a person, or to an issue.
• It doesn’t rank by what is built. A thing that exists can get a page; a thing nobody will care about cannot get an audience.
• It doesn’t invent. A candidate with no pull request, note or meeting behind it is not written.

Triggers

Runs when you ask (“what did we ship”, “plan the week”, “launch the CLI”). Daily checks need a verified scheduler and your approval; otherwise it runs one bounded read now and saves where it got to.