菜单
Read completed tickets from Linear, Jira, or GitHub Issues, filter to user-visible changes, group by product area, and write polished user-facing release notes saved as a .docx to Google Drive. Use before each release or on a weekly cadence.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/amplitude/builder-skills --skill release-notes-generator命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Instrument a Node/TypeScript MCP server with Amplitude's @amplitude/mcp-analytics SDK so tool calls, sessions, and rationale are tracked as Amplitude events. Use this skill whenever the user wants to add Amplitude analytics to their MCP server, mentions "MCP Analytics", "@amplitude/mcp-analytics", "instrument my MCP server", "track MCP tool calls", "add rationale to my MCP tools", or wants agent traffic (Claude, Cursor, ChatGPT) attributed back to Amplitude. Also use for adding UTM tagging to MCP-returned links, or for troubleshooting identity/user_id mismatches between MCP events and web/mobile Amplitude data.
Guide an Amplitude user through building a custom agent by suggesting use cases grounded in their role and data, shaping the idea into a well-formed spec, and generating a ready-to-run Global Agent deeplink that creates it. Use to create, build, or set up a custom agent, automate a recurring analysis, or put a repeated report on a schedule.
Analyze MCP server usage instrumented with Amplitude's MCP Analytics SDK: break usage and errors down by tool, read the rationales within each tool to see what callers are trying to do, and produce a prioritized write-up of actionable fixes. Use this skill whenever the user asks to understand how their MCP server is being used, what agents/users are trying to do with it, why tool calls are failing, what to fix or improve in their MCP server, or asks for an "MCP usage report", "tool error analysis", "intent analysis", "rationale clustering", or "MCP insights". Also trigger when the user mentions [MCP]-prefixed events, tool rationale, tool call errors, or just finished instrumenting their MCP server and wants to see what the data says. Requires the Amplitude MCP connector.
基于 SOC 职业分类
正在显示 SKILL.md
| name | release-notes-generator |
| description | Read completed tickets from Linear, Jira, or GitHub Issues, filter to user-visible changes, group by product area, and write polished user-facing release notes saved as a .docx to Google Drive. Use before each release or on a weekly cadence. |
| suggest_when | User says "release notes", "write changelog", "what shipped this sprint", "draft release notes", "summarize what we shipped", or needs to communicate recent product changes to customers or stakeholders. |
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.