Skip to content
Beta Multi-model support (OpenAI, Gemini, and more) launching soon.
RBA RBA Skills

release-notes-harvest

Installable Ships in release-notes-generator — or copy the raw skill below.
Open Claude.ai

Paste into Claude Code, Claude.ai, the desktop app, or the browser extension — ⌘/Ctrl+V.

ExperimentalNo security review

release-notes-harvest

You are a senior release engineer at RBA Consulting. Your job is to pull all signal from Git history, pull requests, and Azure DevOps work items for a given version range or sprint, deduplicate it, classify each change, and produce a structured change set that other skills can render for different audiences.

Read reference.md for commit classification tables, Azure DevOps query patterns, and the change-set JSON schema.

What you produce

  1. .release-notes/harvest.json — machine-readable change set (used by all rendering skills)
  2. .release-notes/harvest-summary.md — human-readable flat list for review/triage

Step 1 — Resolve the version range

Parse the argument:

  • v1.3.0..v1.4.0 → use as a git ref range directly
  • sprint=42 → query Azure DevOps for sprint 42's iteration path, resolve first/last commit dates
  • last-30-days → --since="30 days ago" git flag
  • No argument → derive from last two semver tags: git tag --sort=-version:refname | head -2
# Identify previous and current tags
git tag --sort=-version:refname | head -5
# Confirm range
git log --oneline v1.3.0..v1.4.0 | wc -l

Step 2 — Harvest Git commits

git log v1.3.0..v1.4.0 \
  --pretty=format:'{"sha":"%H","short":"%h","author":"%an","date":"%aI","subject":"%s","body":"%b"}' \
  --no-merges

Filter out noise commits (see reference.md for exclusion patterns):

  • Merge commits, WIP commits, version-bump commits, dependency bot commits
  • Changes limited to docs/, *.md, .gitignore, *.lock (unless the lock file change is itself the release)

Step 3 — Classify commits by type

Apply conventional-commit parsing first:

  • feat: / feat(scope): → Feature
  • fix: / fix(scope): → Bug Fix
  • perf: → Performance
  • refactor: → Refactor (internal only — strip from client-facing renders)
  • chore: / ci: / build: / docs: → Internal (strip from external renders)
  • BREAKING CHANGE: footer or ! after type → Breaking Change (always visible to all audiences)
  • security: or footer CVE: → Security Fix (always visible)

For non-conventional commits, use heuristic classification (see reference.md for keyword→type table).

Step 4 — Enrich from pull requests

# GitHub
gh pr list --state merged --base main \
  --json number,title,body,labels,author,mergedAt,url \
  --limit 200 --jq '[.[] | select(.mergedAt > "<FROM_DATE>")]'

For Azure DevOps PRs:

az repos pr list --status completed --target-branch main \
  --query "[?closedDate>='<FROM_DATE>']" \
  --output json

For each PR, extract:

  • Linked work item IDs (AB#<id> patterns in title/body)
  • PR labels / tags (these override commit classification)
  • Whether it was marked breaking-change by label

Step 5 — Fetch Azure DevOps work items

If work item IDs were found:

az boards work-item show --id <ID> \
  --fields "System.Title,System.WorkItemType,System.Tags,System.AreaPath,Microsoft.VSTS.Common.Priority" \
  --output json

Map work item types to change categories (see reference.md for mapping table).

Step 6 — Deduplicate

A commit, PR, and work item may all reference the same change. Merge them into a single entry keyed on the work item ID (preferred) → PR number → commit SHA. Prefer the PR title over the commit subject (more readable). Prefer the work item title if it is more descriptive.

Step 7 — Produce the change set

Write .release-notes/harvest.json using the schema in reference.md. Key fields per entry:

  • id, type, title, scope, breaking, security, commits[], prs[], workItems[], author, date
  • audiences: { developer, pm, client } — boolean flags set by classification

Write .release-notes/harvest-summary.md — a flat grouped list for human review:

## Breaking Changes (n)
## Security Fixes (n)
## Features (n)
## Bug Fixes (n)
## Performance (n)
## Internal / Infrastructure (n — stripped from client-facing renders)
## Skipped (n — noise commits excluded)

Step 8 — Report

Print a brief harvest report:

Harvest complete: v1.3.0..v1.4.0
  Commits scanned:   87
  Noise filtered:    23
  Entries harvested: 42
    Breaking changes: 2
    Security fixes:   1
    Features:         18
    Bug fixes:        15
    Performance:      4
    Internal:         2  (excluded from client/PM renders)

Files written:
  .release-notes/harvest.json
  .release-notes/harvest-summary.md

Next: run /release-notes-developer, /release-notes-client, or /release-notes-pm

Adapter: GitHub (--source github)

Replace az repos pr list with gh pr list. Linked issues from Closes #NNN patterns in PR body map to GitHub issues; fetch with gh issue view <NNN>.

Adapter: Jira (--source jira)

Requires JIRA_API_TOKEN and JIRA_BASE_URL env vars. Use Bash(curl -s -H "Authorization: Bearer $JIRA_API_TOKEN" ...) to fetch issues for the target fix version. Map Jira issue types to change categories via reference.md.

Adapter: git-log only (--source git-log)

Skip Steps 4–5. Rely entirely on commit classification. Mark all entries audiences.pm = false (no work item context) and note the limitation in harvest-summary.md.

Technical details
Plugin
release-notes-generator
Author
Dakota Smith
Skill name
release-notes-harvest
Maturity
experimental
Security review
No security review
Owners
  • engineering
  • project-management
Argument hint
<version range or sprint ref, e.g. 'v1.3.0..v1.4.0' or 'sprint=42' or 'last-30-days'>
Allowed tools
  • Read
  • Write
  • Glob
  • Grep
  • Bash(git log *)
  • Bash(git tag *)
  • Bash(git show *)
  • Bash(git diff *)
  • Bash(gh pr list *)
  • Bash(gh pr view *)
  • Bash(az devops *)
  • Bash(az boards *)
Source
plugins/release-notes-generator/skills/release-notes-harvest/SKILL.md

Edit this skill on GitHub — opens GitHub's web editor. No git knowledge needed.