claude-plugins/plugins/save-doc/commands/release-notes.md

description	allowed-tools
Save release notes for a deployment to the knowledge base	Read,Write,Edit,Glob,Grep,Bash

Save release notes documenting a deployment. Gathers context from git history and produces a structured KB document.

Defaults

• type: reference
• tags: always include release-notes and deployment
• filename: release-YYYY.M.DD.md (or database-release-YYYY.M.DD.md for DB-only releases)
• save path: /mnt/NV2/Development/claude-home/{domain}/

Gathering Context

Before writing, collect what you can automatically:

1. Git log — recent commits on main since last tag or last release notes
2. Tags — latest CalVer tag for the version number
3. PRs — merged PR numbers and titles if available
4. Ask the user for anything you can't determine: target server, deploy method, image tag, domain

Document Structure

---
title: "{Project} Release — YYYY.M.DD"
description: "One-line summary of what this release covers."
type: reference
domain: {domain}
tags: [release-notes, deployment, ...]
---

# {Project} Release — YYYY.M.DD

**Date:** YYYY-MM-DD
**Tag:** `{calver or semver tag}`
**Image:** `{docker image}` (if applicable)
**Server:** {target host} (`{deploy path}`)
**Deploy method:** {how it was deployed}

## Release Summary

One paragraph overview of the release.

## Changes

### New Features
- ...

### Bug Fixes
- ...

### Dependencies
- ...

## Infrastructure Changes
(Only if applicable — CI, Docker, config changes)

## Hotfix During Release
(Only if a hotfix was needed — include root cause and lesson)

## Deployment Notes
- Migration commands, config changes, rollback instructions
- Rollback: {how to roll back}

Rules

• Omit empty sections — only include sections that have content
• Use PR numbers as references (e.g., "PR #88") when available
• Include rollback instructions when the deployment method supports it
• For database-only releases, prefix filename with database-
• If the user provides partial info, fill in what you can and ask about the rest