Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
From execution-skills
Generates polished user-facing release notes from completed Linear, Jira, or GitHub Issues tickets: filters visible changes, groups by product area, saves .docx to Google Drive before releases or weekly.
npx claudepluginhub amplitude/builder-skills --plugin execution-skillsHow this skill is triggered — by the user, by Claude, or both
Slash command
/execution-skills:release-notes-generatorThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Turn a sprint's worth of closed tickets into polished, user-facing release notes — automatically.**
Generates user-facing release notes from tickets, PRDs, changelogs, or Git logs. Organizes into categories like new features, improvements, bug fixes for product announcements.
Generates user-facing release notes from tickets, PRDs, changelogs, or Git logs. Categorizes into new features, improvements, bug fixes with benefit-focused summaries for product updates.
Share bugs, ideas, or general feedback.
Turn a sprint's worth of closed tickets into polished, user-facing release notes — automatically.
Writing release notes from raw tickets is tedious: filter out internal work, translate engineer-speak into user language, format consistently. This skill does all of it.
/schedule
### Step 1 — Gather completed tickets
Check {{TICKET_SOURCES}} for items marked done, shipped, merged, or closed in the past {{TIME_WINDOW}}.
Skip: in-progress, internal-only, pure bug fixes with no visible UX change, chores, refactors,
anything tagged "internal", "infra", or "ops".
### Step 2 — Group by product area
Use ticket labels or project names. Merge areas with fewer than 2 items into the closest group.
### Step 3 — Write the release notes
For each area:
**[Area Tag]**
**[Title]** — 2–5 words, present tense, feature name not a commit message.
Good: "Faster search results", "New billing dashboard". Never: "added", "fixed", "shipped".
[Description] — 1–3 sentences to the user. Lead with what changed and why it matters.
Use "you can now…" framing. No bullet points. No ticket IDs, sprint names, or engineer names.
### Step 4 — Save
Date at top: Month DD, YYYY. Entries grouped by area.
Save as ReleaseNotes_YYYY-MM-DD.docx to {{OUTPUT_FOLDER}}.
Do not publish — save for review only. If no tickets found, say which sources you checked.
| Field | Value |
|---|---|
| MCPs required | Linear / Jira / GitHub Issues, Google Drive |
| Output | ReleaseNotes_YYYY-MM-DD.docx → /Product/ReleaseNotes |
| Scheduler | Manual before each release, or weekly |
{{TICKET_SOURCES}} — e.g. Linear, Jira, or GitHub Issues{{TIME_WINDOW}} — e.g. the past 7 days, the past 2 weeks, or this sprint{{OUTPUT_FOLDER}} — e.g. /Product/ReleaseNotesupdate-knowledge-base to flag which help articles need updating after each release.