release_changelog.md

name	description
release-changelog-demo	Generate a structured release changelog between two git tags, optionally enriched with issue tracker (e.g. Jira) and feature-flag (e.g. GrowthBook) data. Use when the user asks for a changelog, release notes, or diff between two release tags.

Release Changelog Generator (Demo / Public Template)

Generate a changelog between two git tags. Optionally enrich with data from an issue tracker and a feature-flag service, and format for internal distribution (e.g. Slack, docs).

Inputs

The user provides:

• $PREVIOUS_TAG — previous production (or baseline) tag
• $NEXT_TAG — tag just released (or target)
• (Optional) Repo list and base URLs for commit links

Repos to track

Run git log for each tracked repo, for example:

git log $PREVIOUS_TAG..$NEXT_TAG --no-merges

Use your own VCS base URL for commit links (e.g. https://gitlab.com/org/repo/-/commit/ or https://github.com/org/repo/commit/).

Data sources

1. Git CLI (primary)

git log $PREVIOUS_TAG..$NEXT_TAG --format="%H|%s|%an|%ad" --no-merges --date=short

Optionally include reverts and cherry-picks:

git log $PREVIOUS_TAG..$NEXT_TAG --no-merges --grep="Revert" --grep="cherry" --format="%H|%s|%an"

2. Issue tracker (e.g. Jira)

• Configure your instance (e.g. Jira Cloud ID or API base URL).
• Extract unique ticket keys from commit subjects (e.g. [A-Z]+-\d+).
• Batch-query tickets (e.g. JQL: key in (TICKET1, TICKET2, ...)).
• Fetch fields such as: summary, status, issuetype, priority.

3. Feature flags (e.g. GrowthBook)

• Configure your project (e.g. GrowthBook project ID).
• Fetch recent feature flags (e.g. limit 100, most recent first).
• Match flags to the release by keyword search on flag id and description (ticket keys are often not stored verbatim).
• For each matched flag, inspect production environment:
  • DISABLED — enabled: false
  • Enabled but default off — enabled: true, no/disabled rules, defaultValue: "false"
  • Partially enabled — rules with conditions (user IDs, segments, etc.)
  • Enabled for everyone — enabled: true with rules forcing true for all or defaultValue: "true"

Execution strategy

Maximize parallelism:

1. Parallel: Git log for all repos + feature-flag list fetch.
2. Sequential: Extract ticket keys from git logs and deduplicate.
3. Parallel: Issue-tracker batch queries + per-flag detail lookups (e.g. max 4 concurrent).
4. Sequential: Compile and write the changelog file.

Link formats

• With ticket: [TICKET-123](<your-issue-tracker-url>/TICKET-123) - description
• No ticket: **NOJIRA** (or **NO-TICKET**) - description
• Support your project key pattern (e.g. PROJ-123, TEAM-456).

Output file

Write to: CHANGELOG_$PREVIOUS_TAG--$NEXT_TAG.md (or append _slack.md if you have a Slack-specific variant).

Output structure

Markdown

# Changelog: `$PREVIOUS_TAG` → `$NEXT_TAG`

**Date:** YYYY-MM-DD
**Previous tag:** `$PREVIOUS_TAG`
**Released tag:** `$NEXT_TAG`
**Repos:** list repos that had changes

---

## Reverts & Cherry-picks
*(Only if any exist)*  
Table of reverts/cherry-picks with commit and original commit if identifiable.

## New Features
Group by theme. Each group:
- Bulleted ticket links with descriptions
- **Feature flag:** flag name, production status, link to flag (if applicable)

## Risky Changes (Requires Monitoring)
Table: Ticket | Risk Type | Details  
Risk types (customize to your product): e.g. DATA MIGRATION, AUTH, PERMISSIONS, LOGGING/PRIVACY, INFRASTRUCTURE, PAYMENT, REALTIME

## Fixes & Improvements
Brief bullets

## Tests & CI
Bullet list

## Other
Chore, tooling, commits without ticket

## Feature Flag Summary
Table: Flag | Related Tickets | Prod Status (with links if applicable)

## Top-N Contributors
Table: Author | Commits | Areas  
Sorted by commit count descending.

---

**Total commits:** N (breakdown by repo if multiple)
**Focus areas:** 1–2 lines summarizing main themes

## Raw Commit Links
Grouped by repo, with your VCS base URL

## Raw Ticket Links
Deduplicated, sorted by project then number

Quality checks

Before writing:

• Verify ticket keys resolve in the issue tracker (warn on 404).
• List commits without a ticket key under "Other".
• Ensure all linked feature flags and tickets are valid.