release-fanout

A QM skill pack. One merged PR goes in, four audience-specific drafts come out, side by side, for a human to approve.

Built against calcom/cal.diy (the Cal.com product repo, renamed from calcom/cal.com) because it is a public commercial product: real users, real help center, real developer API, real sales motion. Every audience has a true referent, so nothing in the output is invented. Point it at a different repo by changing the coordinates in pr-fanout.

The four audiences

Skill	Reader	Lands in
changelog-entry	existing user skimming what's new	public changelog
support-macro	someone already stuck	help center, canned reply
developer-note	someone building on the API or embed	API docs, migration note
sales-talking-point	Enterprise and Organizations motion	battlecard, follow-up email

pr-fanout is the orchestrator the cron runs. It triages first, fans out second.

The rule that keeps this honest: if any two outputs could swap places, you have three audiences, not four.

Install

Import as a skill pack from git (Skills, then Add pack), or drop these directories into deploy/layers/<org>/skills/.

Grant one skill per scope if you want the real multiplayer shape: docs scope owns changelog-entry, support owns support-macro, and so on. A single scope holding all four works too and is the faster path for a first run.

Create the cron

Crons are runtime objects in QM, not files. Ask an agent in the scope that owns pr-fanout:

Create a cron named "cal.diy release fanout" that runs hourly, runs the pr-fanout skill, and delivers to #release-drafts.

Or via POST /crons:

{
  "title": "cal.diy release fanout",
  "schedule": { "every": "1h" },
  "action": "Run the pr-fanout skill for calcom/cal.diy.",
  "destination": { "channel": "#release-drafts" }
}

Confirm the schedule shape against src/cron/schedule.ts in your QM version before relying on it unattended. Fire it manually once first.

Demo PRs

The live PR stream is mostly chores and i18n fixes, which the triage gate correctly drops. Pre-selected merges that actually exercise the fan-out:

• #29819 feat: add Clara app — all four audiences light up. The easy win.
• #29685 fix(bookings): refund all seat payments when cancelling a paid seated event — money behavior. Support and changelog are strong, the developer note matters.
• #29708 fix(emails): send METHOD:CANCEL in ICS for cancelled bookings — the developer note is the star, because calendar clients behave differently now.
• #29857 fix: trim whitespace in parseIpFromHeaders to prevent IP banlist bypass — the interesting one. A security fix where the right answer is "changelog yes, sales no, and say less than you know." Good argument to have on camera.

Run these by hand, then leave the cron armed so a live merge is a bonus rather than a dependency.