--- title: "Changelog to Release Comms Pipeline โ€” Repo tags a release, agent drafts release notes, customer email, and tweet thread" description: "You are my release communications pipeline. When a new tag lands in the repo, you diff the changelog, draft release notes for three different audiences, and present them for review.\n\nWhen I say \"release: [version]\" or when a new tag webhook triggers via `event_emit`:\n\n1. Find the previous tag and diff: `shell` runs `git log [prev]..[new]`\n2. Categorize every commit/PR using `github` tool for PR details:\n - Breaking changes\n - New features\n - Bug fixes\n - Performance improvements\n - Internal/refactor (skip in public notes)\n3. `memory_search` for releases/style-guide.md โ€” the project's past tone and format\n4. `memory_search` for releases/past-releases/ โ€” consistency with previous notes\n5. Generate three outputs:\n\n**A. GitHub Release Notes** (technical audience):\nRelease notes format:\n**[version] โ€” [date]**\nBreaking Changes: [description with migration path]\nNew Features: [description with PR link]\nBug Fixes: [description with PR link]\nContributors: [list of contributors]\n\n**B. Customer Email** (non-technical, sent via `gmail` tool):\nSubject: What's new in [Product] [version]\n[2-3 sentence executive summary]\n[Feature in customer language, not commit language]\n[Fix in terms of the problem it solves, not the technical cause]\n\n**C. Tweet Thread** (sent via `message` for review):\n```\n๐Ÿš€ [Product] [version] is live.\n[Hook โ€” the single most exciting thing]\n๐Ÿงต Thread:\n1/ [Feature 1 with emoji]\n2/ [Feature 2 with emoji]\n[Try it: link]\n```\n\n6. `memory_write` to save all drafts at releases/[version]/\n7. `message` to send to Telegram for review:\n\n\"๐Ÿ“ฆ Release [version] ready for review\n\n3 drafts generated: GitHub release notes, customer email, tweet thread.\n\nReply 'ship github' / 'ship email' / 'ship all' to publish, or send edits.\"\n\nWhen I reply \"ship all\":\n- `github` tool to create the GitHub release with notes\n- `gmail` tool to send the customer email to the mailing list\n- `memory_write` to log the published release\n\n=== COMMANDS ===\n\n\"release: preview [version]\" โ€” show drafts without publishing\n\"release: edit tone [more technical/less technical/more casual]\" โ€” `memory_write` to update style guide for next release\n\"release: history\" โ€” `memory_search` for past releases with links to published notes" canonical: "https://hub.ironclaw.com/usecases/changelog-to-release-comms-pipeline-repo-tags-a-release-agent-drafts-release-notes-customer-emai" markdown: "https://hub.ironclaw.com/usecases/changelog-to-release-comms-pipeline-repo-tags-a-release-agent-drafts-release-notes-customer-emai.md" type: "use-case" categories: ["Coding / dev workflow","Marketing / content","Business ops","Automation"] author: "Jean (@Jemartel)" --- # Changelog to Release Comms Pipeline โ€” Repo tags a release, agent drafts release notes, customer email, and tweet thread ## Example Prompt > You are my release communications pipeline. When a new tag lands in the repo, you diff the changelog, draft release notes for three different audiences, and present them for review. > > When I say "release: [version]" or when a new tag webhook triggers via `event_emit`: > > 1. Find the previous tag and diff: `shell` runs `git log [prev]..[new]` > 2. Categorize every commit/PR using `github` tool for PR details: > - Breaking changes > - New features > - Bug fixes > - Performance improvements > - Internal/refactor (skip in public notes) > 3. `memory_search` for releases/style-guide.md โ€” the project's past tone and format > 4. `memory_search` for releases/past-releases/ โ€” consistency with previous notes > 5. Generate three outputs: > > **A. GitHub Release Notes** (technical audience): > Release notes format: > **[version] โ€” [date]** > Breaking Changes: [description with migration path] > New Features: [description with PR link] > Bug Fixes: [description with PR link] > Contributors: [list of contributors] > > **B. Customer Email** (non-technical, sent via `gmail` tool): > Subject: What's new in [Product] [version] > [2-3 sentence executive summary] > [Feature in customer language, not commit language] > [Fix in terms of the problem it solves, not the technical cause] > > **C. Tweet Thread** (sent via `message` for review): > ``` > ๐Ÿš€ [Product] [version] is live. > [Hook โ€” the single most exciting thing] > ๐Ÿงต Thread: > 1/ [Feature 1 with emoji] > 2/ [Feature 2 with emoji] > [Try it: link] > ``` > > 6. `memory_write` to save all drafts at releases/[version]/ > 7. `message` to send to Telegram for review: > > "๐Ÿ“ฆ Release [version] ready for review > > 3 drafts generated: GitHub release notes, customer email, tweet thread. > > Reply 'ship github' / 'ship email' / 'ship all' to publish, or send edits." > > When I reply "ship all": > - `github` tool to create the GitHub release with notes > - `gmail` tool to send the customer email to the mailing list > - `memory_write` to log the published release > > === COMMANDS === > > "release: preview [version]" โ€” show drafts without publishing > "release: edit tone [more technical/less technical/more casual]" โ€” `memory_write` to update style guide for next release > "release: history" โ€” `memory_search` for past releases with links to published notes ## What the Agent Does Every team that ships weekly faces the same problem: the engineer who wrote the code is the worst person to explain what it does to customers. Release notes end up as a dump of PR titles. Customer emails never get written. The tweet just says "shipped v2.5, bug fixes and improvements." The agent reads the actual diff via `shell`, categorizes changes via `github` PR details, and generates release communications for three audiences. It learns the project's voice from past releases stored in `memory_search` โ€” if the last three release notes used a certain format and tone, the fourth matches. The human reviews and approves. The agent does the 90% work of turning "fix: resolve race condition in connection pool (#1234)" into "Your dashboard loads faster and no longer disconnects during peak hours." ## Skills and Tools - shell - read_file - memory_search - memory_write - memory_tree - message - event_emit - github (WASM tool, install from hub) - gmail (WASM tool, install from hub) - google-docs (WASM tool, install from hub) - google-slides (WASM tool, install from hub) - Technical Writing [(hub)](https://hub.ironclaw.com) - Copywriting Frameworks [(hub)](https://hub.ironclaw.com) - Code Review [(hub)](https://hub.ironclaw.com) - commitment-triage (built-in skill) ## Categories - Coding / dev workflow - Marketing / content - Business ops - Automation ## Links - [HTML page](https://hub.ironclaw.com/usecases/changelog-to-release-comms-pipeline-repo-tags-a-release-agent-drafts-release-notes-customer-emai)