Release Notes Generator

Generate SEO-optimized GitHub release notes for kwin-mcp.

Usage

/release-notes <version>

Example: /release-notes v0.5.1

Instructions

Step 1: Gather Context

1. Read CHANGELOG.md and find the entry for the specified version
2. Read pyproject.toml to confirm the current version and project metadata
3. Check existing GitHub releases for style consistency:

   gh release list --limit 5
   gh release view <previous-version>

Step 1.5: Verify plugin manifests + bundled SKILL.md are in sync

Before generating release notes, ensure all integrations (.claude-plugin/marketplace.json, integrations/claude-code/.claude-plugin/plugin.json, integrations/opencode/plugin/package.json, and the OpenCode plugin's bundled SKILL.md) reflect the version being released:

python3 scripts/sync_plugin_version.py        # write synced state
python3 scripts/sync_plugin_version.py --check # verify (CI also runs this)

If new MCP tools were added or renamed in this release, also confirm that integrations/claude-code/skills/kwin-desktop-automation/SKILL.md reflects them — the OpenCode plugin auto-mirrors that file on its next npm run build. The release notes' New Tools table should match what the SKILL.md exposes.

Step 2: Determine Release Type

• Patch release (x.y.Z): bug fixes, minor improvements
• Minor release (x.Y.0): new features, new tools, non-breaking changes
• Major release (X.0.0): breaking changes

Step 3: Generate Release Notes

#### Minor+ Release Template

kwin-mcp vX.Y.Z <one-line value proposition with primary keywords>.

## Highlights

- **Feature name**: Description mentioning exact technology (AT-SPI2, libei, EIS, D-Bus, etc.)
- **Feature name**: Description with concrete numbers (e.g. "17 new MCP tools")
- ...

## New Tools

| Tool | Description |
|------|-------------|
| `tool_name` | What it does |
| ... | ... |

## Installation

\```bash
# Using uv (recommended)
uv tool install kwin-mcp

# Using pip
pip install kwin-mcp
\```

**Full Changelog**: https://github.com/isac322/kwin-mcp/compare/vPREVIOUS...vCURRENT

#### Patch Release Template

kwin-mcp vX.Y.Z <one-line summary of what was fixed/improved>.

## What's Changed

- **Change description**: Detailed explanation mentioning exact technologies and tool names

**Full Changelog**: https://github.com/isac322/kwin-mcp/compare/vPREVIOUS...vCURRENT

Step 4: SEO Rules for Release Notes

• Language: Always English
• First sentence: Must convey the value proposition (what the user gains)
• Technology names: Always use exact names — AT-SPI2, libei, EIS, KWin ScreenShot2, D-Bus, PyGObject, wl-clipboard, wtype
• Tool names: Use backtick code format with bare names (e.g. mouse_click, accessibility_tree). Hosts add their own prefix (mcp__kwin-mcp__* for Claude Code, kwin-mcp_* for OpenCode) — never hardcode prefixes in release notes
• Tool counts: Include total tool count when relevant (e.g. "now with 29 MCP tools"). When the count changes, also update .claude/positioning.yml § product.tool_count, .claude/positioning.yml § drift_detection.tool_count_canonical, check_docs_seo.py § TOOL_COUNT_CANONICAL, README tool tables, and the SKILL.md "X capabilities" reference before tagging the release
• Plugin sync: If the release ships new tools, mention that the bundled plugins were updated. Existing users will see the new guidance after a /plugin update (Claude Code) or after the OpenCode plugin's next npm run build mirrors the SKILL.md
• Comparison link: Always end with a Full Changelog comparison link
• No emojis: Do not use emojis in release notes

Step 5: Present for Review

Show the generated release notes to the user for review before creating the GitHub release. Ask for confirmation before running:

gh release create vX.Y.Z --title "vX.Y.Z" --notes "..."