AgentSkillsCN

Release Notes

版本说明

SKILL.md

Release Notes Generator

Generate release notes for an ElasticGraph release.

Usage

Invoke with: /release-notes <new-version> [--from <previous-version>]

Version numbers should NOT include the "v" prefix (the skill will add it as needed for git tags).

Examples:

  • •/release-notes 1.1.0 - generates notes from latest release to HEAD
  • •/release-notes 1.1.0 --from 1.0.2 - generates notes from v1.0.2 to HEAD

Instructions

You are generating release notes for ElasticGraph. Follow this workflow:

Step 1: Determine Version Range

  1. •Parse the version argument (e.g., "1.1.0") - no "v" prefix expected
  2. •If --from is provided, use that as the base version (e.g., "1.0.2")
  3. •Otherwise, find the most recent release tag using gh release list --limit 1
  4. •Fetch tags if needed: git fetch --tags
  5. •When referencing git tags, prepend "v" (e.g., version "1.0.2" becomes tag "v1.0.2")

Step 2: Gather PR Information

  1. •Get all commits since the base version:
    bash
    git log v<base-version>..HEAD --oneline
  2. •Get all merged PRs with details:
    bash
    gh pr list --state merged --base main --search "merged:>=<release-date>" --limit 200 --json number,title,author,url,mergedAt
  3. •For key PRs, fetch full details:
    bash
    gh pr view <number> --json title,body

Step 3: Review Release Note Format

  1. •Read MAINTAINERS_RUNBOOK.md for release note structure guidelines
  2. •Fetch 1-2 recent release notes for format reference:
    bash
    gh release view <recent-version> --json body

Step 4: Categorize PRs

Group PRs into these categories:

  • •New Features: New functionality, new gems, new APIs
  • •Performance Optimizations: Speed improvements, resource efficiency
  • •Bug Fixes: Corrections to existing behavior
  • •Other Improvements: Documentation, tooling, refactoring, cleanup
  • •Dependency Upgrades: Grouped by type (Ruby gems, GitHub Actions, NPM, Python)

Guidelines:

  • •Multiple PRs implementing one feature should be combined into one bullet
  • •Internal-only changes (CI fixes, codebase cleanup) go under "Other Improvements"
  • •Dependabot PRs are grouped under "Dependency Upgrades" with all PR numbers listed

Step 5: Identify New Contributors

  1. •Get all contributors since base version
  2. •Get all contributors before base version
  3. •New contributors = those in first list but not second
  4. •List them with their first PR

Step 6: Draft Release Notes

Structure:

code
ElasticGraph v<VERSION> has been released! <1-2 sentence summary>

## New Features
### <Feature Name>
Description of major features with their own subsections.

## Upgrade notes
Any breaking changes or required migration steps.

## What's Changed

### New Features
* Description by @author in [#PR](url), [#PR](url)...

### Performance Optimizations
* Description by @author in [#PR](url)...

### Bug Fixes
* Description by @author in [#PR](url)...

### Other Improvements
* Description by @author in [#PR](url)...

### Dependency Upgrades
The datastore versions we build against have been upgraded:
* Elasticsearch: X.Y -> A.B ([#PR](url))
* OpenSearch: X.Y -> A.B ([#PR](url))

The following Ruby gems have been upgraded:
* gem-name: X.Y -> A.B ([#PR](url))
...

The following GitHub actions have been upgraded:
* Multiple actions via Dependabot ([#PR](url), ...)

The following NPM packages have been upgraded:
* package: X.Y -> A.B ([#PR](url), ...)

The following Python packages have been upgraded:
* package: X.Y -> A.B ([#PR](url), ...)

## New Contributors
* @username made their first contribution in [#PR](url)

---

**Full Changelog**: https://github.com/block/elasticgraph/compare/v<base>...v<VERSION>

Step 7: Audit Coverage

  1. •Count total PRs since base version (exclude release PRs like "Release vX.Y.Z")
  2. •Count PRs mentioned in release notes
  3. •Identify any missing PRs and add them to appropriate sections
  4. •Ensure 100% coverage

Step 8: Present for Review

Output the complete release notes and ask if any adjustments are needed.

Notes

  • •The audience is ElasticGraph users - focus on user-facing changes
  • •Internal improvements can be grouped (e.g., "Various codebase maintenance")
  • •For pre-releases (rc1, rc2), use GitHub's autogenerated notes instead
  • •Check versioning policy if unsure whether version should be major/minor/patch