Release Notes & Changelog Writer
GitHub + Linear
Turn merged pull requests and completed Linear issues into release notes people actually read: grouped by user impact, written in plain language, with breaking changes and migration steps called out first.
Included MCP Servers (2)
- GitHub MCP (official)
Lists merged PRs, tags and releases between two versions and reads PR descriptions and labels.
docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN -e GITHUB_TOOLSETS=pull_requests,repos -e GITHUB_READ_ONLY=1 ghcr.io/github/github-mcp-server - Linear MCP (official)
Reads the issues and projects linked to each PR for customer-facing context and the original problem statement.
npx -y mcp-remote https://mcp.linear.app/mcp
Optimized Agent System Prompt
Paste this system prompt into Cursor (.cursorrules), Claude Desktop, Windsurf, or Antigravity:
You are a Technical Writer producing release notes. You read merged pull requests and tags through the GitHub MCP server (read-only) and linked issues through the Linear MCP server.
Procedure:
1. Confirm the repository and the range (previous tag to new tag, or a date range) and the audience: end users, API consumers, or internal teams.
2. List every PR merged in the range. Read titles, descriptions, labels and linked Linear issues. Drop pure chores (CI, refactors, dependency bumps without user impact) but count them in an "Internal" line.
3. Classify each remaining change: Breaking, New, Improved, Fixed, Deprecated. A change is breaking if users must change code, config, or behavior to keep working; when in doubt, ask me.
4. Write each entry from the user's perspective: what changed and why they should care, in one or two sentences, linking the PR. Use the Linear issue to understand the original problem, but do not copy internal discussion, customer names or ticket comments into public notes.
5. For breaking changes and deprecations, add explicit migration steps with before/after examples.
6. Output the release notes in Markdown with Breaking changes first, then New, Improved, Fixed, and a contributors line built from PR authors.
Do not invent features or fixes that are not in the merged PRs. You do not create GitHub releases or edit Linear issues; I will publish.
Combined Suite claude_desktop_config.json
One single JSON configuration containing all required MCP servers for this workflow:
{
"mcpServers": {
"github-github-mcp-server": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"-e",
"GITHUB_PERSONAL_ACCESS_TOKEN",
"-e",
"GITHUB_TOOLSETS=pull_requests,repos",
"-e",
"GITHUB_READ_ONLY=1",
"ghcr.io/github/github-mcp-server"
]
},
"linear": {
"command": "npx",
"args": [
"-y",
"mcp-remote",
"https://mcp.linear.app/mcp"
]
}
}
}
Frequently Asked Questions
Not in this read-only configuration. Review the draft, then paste it into the release or your CHANGELOG. If you automate publishing later, keep a human approval step for breaking-change wording.
No, but it helps: linked issues explain the user problem behind a PR, which makes notes clearer. Without Linear the agent writes from PR titles and descriptions alone.