Skip to content

Commit b86f0e6

Browse files
dlvenabledlvenable
committed
Adds prompts for creating Data Prepper release notes using AI tools. This allows us to use AI to create the release notes consistently between versions and across different maintainers. They are geared toward Claude but should work for tools like Kiro.
Signed-off-by: David Venable <dlv@amazon.com>
1 parent cf682e7 commit b86f0e6

4 files changed

Lines changed: 243 additions & 3 deletions

File tree

‎.claude/commands/generate-release-notes.md‎

Lines changed: 135 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,135 @@
1+
Generate release notes for Data Prepper version $ARGUMENTS.
2+
3+
## Overview
4+
5+
You are generating user-facing release notes for the OpenSearch Data Prepper project.
6+
The milestone to use is: $ARGUMENTS
7+
8+
You will gather data from GitHub, categorize each item, reword it for clarity, and produce
9+
a release notes file following the project's established format.
10+
11+
## Step 1: Gather Data
12+
13+
Run these commands to fetch all closed issues and PRs for the milestone.
14+
Request the fields: number, url, title, labels, body.
15+
16+
```
17+
gh issue list --repo opensearch-project/data-prepper --search 'milestone:$ARGUMENTS' --state closed --json number,url,title,labels,body --limit 200
18+
```
19+
20+
```
21+
gh pr list --repo opensearch-project/data-prepper --search 'milestone:$ARGUMENTS' --state closed --json number,url,title,labels,body --limit 200
22+
```
23+
24+
Collect all results. Note which items are issues vs PRs.
25+
26+
## Step 2: Read the Label-to-Category Mapping
27+
28+
Read the file `release/script/release-notes/label-category-mapping.md` for the full rules
29+
on how labels map to categories, how to distinguish Features from Enhancements, what to
30+
exclude, and what to consolidate.
31+
32+
## Step 3: Read Example Release Notes for Style
33+
34+
Read 2-3 of the most recent release notes files in `release/release-notes/`. Use only
35+
files matching `data-prepper.release-notes-*.md` -- ignore `data-prepper.change-log-*.md`
36+
files, which are a different format. Study the tone, format, and level of detail.
37+
Key style observations:
38+
39+
- Each item is a single bullet point: `* Description ([#N](url))`
40+
- Descriptions are concise, active, and user-facing
41+
- They describe what changed from the user's perspective, not implementation details
42+
- Multiple related links can appear: `([#N1](url1), [#N2](url2))`
43+
- Security items typically reference the vulnerability issue verbatim
44+
- The date format is YYYY-MM-DD
45+
- Empty categories are kept in the output (the heading with no items below it)
46+
47+
## Step 4: Categorize Each Item
48+
49+
For each issue/PR:
50+
51+
1. **Check exclusion rules first.** Skip release prep PRs, changelog PRs, release notes PRs,
52+
individual dependency bumps, license header updates, and bot housekeeping PRs.
53+
54+
2. **Apply label-based categorization.** Use the mapping rules to assign a category.
55+
56+
3. **Confirm by reading the body.** If the labels suggest one category but the body clearly
57+
indicates another, override the label-based assignment. Pay special attention to:
58+
- Distinguishing Features (new capability) from Enhancements (improving existing)
59+
- Items labeled `enhancement` that are actually bug fixes
60+
- Items with no relevant labels -- categorize based on the body content
61+
62+
4. **Consolidate related items.** When an issue and its implementing PR(s) are both in the
63+
milestone, produce one line. Prefer linking to the issue. If a PR has no corresponding
64+
issue, link to the PR.
65+
66+
## Step 5: Reword Each Item
67+
68+
Rewrite each item to be:
69+
70+
- **Direct and concise**: "Support X" not "Add support for X", "Added support for X",
71+
or "Support for X was added". Lead with the verb, skip filler words.
72+
- **User-facing**: Describe the impact, not the implementation. "Support compressed files
73+
in the file source" not "Add GzipInputStream wrapper to FileSource class"
74+
- **Concise**: One sentence, no trailing periods
75+
- **Specific**: Name the plugin or component when relevant. "Support partition keys in the
76+
OTel metrics source with persistent buffers" not "Support partition keys"
77+
78+
Do NOT use the prefix tags like "feat:", "fix:", "refactor:" from commit messages.
79+
80+
## Step 6: Produce the Output
81+
82+
Write the release notes file to:
83+
`release/release-notes/data-prepper.release-notes-VERSION.md`
84+
85+
where VERSION is derived from the milestone (e.g. milestone `v2.15` produces version `2.15.0`
86+
if it's a minor release).
87+
88+
Use today's date in the header.
89+
90+
Format:
91+
92+
```
93+
## YYYY-MM-DD Version M.m.p
94+
95+
---
96+
97+
### Breaking Changes
98+
99+
* Item ([#N](url))
100+
101+
### Features
102+
103+
* Item ([#N](url))
104+
105+
### Enhancements
106+
107+
* Item ([#N](url))
108+
109+
### Bug Fixes
110+
111+
* Item ([#N](url))
112+
113+
### Security
114+
115+
* Item ([#N](url))
116+
117+
### Maintenance
118+
119+
* Item ([#N](url))
120+
121+
```
122+
123+
Keep all six category headings even if a category has no items.
124+
125+
## Step 7: Review
126+
127+
After writing the file, read it back and check:
128+
- No duplicate items
129+
- No excluded items leaked through
130+
- Items are in the correct categories
131+
- Wording is consistent in style
132+
- All links are correct
133+
134+
Present the final file to the user and note any items where categorization was uncertain
135+
so they can review those specifically.

‎.gitignore‎

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -30,5 +30,6 @@ pipelines.yaml
3030
run-dataprepper.sh
3131
trace-tester.py
3232

33-
# Claude project instructions
33+
# Claude Code
34+
.claude/settings.local.json
3435
CLAUDE.md

‎release/script/release-notes/README.md‎

Lines changed: 40 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,45 @@
11
# Generate Release Notes
22

3-
To help generate release notes, you can use the following script.
4-
It will produce a formatted file, but you need to organize the content and possibly reword or remove.
3+
## AI-Assisted Generation (Recommended)
4+
5+
Use an AI coding assistant to generate categorized, reworded release notes from the GitHub
6+
milestone. The prompt is checked into the repository and can be used with any AI tool.
7+
8+
The prompt file is at: `.claude/commands/generate-release-notes.md`
9+
10+
### Using Claude Code
11+
12+
Claude Code loads this as a slash command automatically:
13+
14+
```
15+
/generate-release-notes v2.15
16+
```
17+
18+
### Using Kiro or Other AI Tools
19+
20+
Ask the AI to read and follow the prompt file, providing the milestone version:
21+
22+
> Read and follow the instructions in `.claude/commands/generate-release-notes.md` for milestone v2.15
23+
24+
### What the AI Does
25+
26+
1. Fetches closed issues and PRs for the milestone using the GitHub CLI
27+
2. Categorizes each item using labels and PR body content (see `label-category-mapping.md`)
28+
3. Rewords items to be active, concise, and user-facing
29+
4. Consolidates related issues/PRs into single entries
30+
5. Excludes internal items (dependency bumps, release prep, license headers)
31+
6. Writes the release notes file to `release/release-notes/`
32+
33+
You should review the output, especially any items the AI flags as uncertain.
34+
35+
### Prerequisites
36+
37+
* [GitHub CLI](https://cli.github.com/) - must be authenticated
38+
* An AI coding assistant (Claude Code, Kiro, etc.)
39+
40+
## Manual Generation (Legacy)
41+
42+
To generate a flat, uncategorized list that requires manual organization:
543

644
You need two tools installed:
745

‎release/script/release-notes/label-category-mapping.md‎

Lines changed: 66 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,66 @@
1+
# Label to Category Mapping for Release Notes
2+
3+
This file defines how GitHub labels map to release note categories.
4+
It is referenced by the release notes generation prompt.
5+
6+
## Categories
7+
8+
The release notes use these fixed categories, in this order:
9+
10+
1. **Breaking Changes**
11+
2. **Features**
12+
3. **Enhancements**
13+
4. **Bug Fixes**
14+
5. **Security**
15+
6. **Maintenance**
16+
17+
## Label Mapping Rules
18+
19+
### Breaking Changes
20+
- `breaking change`
21+
22+
### Bug Fixes
23+
- `bug`
24+
25+
### Security
26+
- `security fix`
27+
- `Mend: dependency security vulnerability`
28+
29+
### Maintenance
30+
- `maintenance`
31+
- `dependencies`
32+
- `ci`
33+
- `github_actions`
34+
- `documentation`
35+
36+
### Features vs Enhancements
37+
38+
Both Features and Enhancements often use the `enhancement` label. Use these rules to distinguish:
39+
40+
**Features** (entirely new capabilities):
41+
- Introduces a new source, processor, sink, or buffer plugin
42+
- Adds a wholly new integration (e.g. new AWS service support)
43+
- Adds a new expression function or operator
44+
- The issue/PR title or body describes something that did not exist before
45+
46+
**Enhancements** (improvements to existing capabilities):
47+
- Adds a configuration option to an existing plugin
48+
- Improves performance of an existing feature
49+
- Extends an existing plugin to support a new format, codec, or protocol
50+
- The `ease-of-use` or `performance` labels are present
51+
52+
When the `enhancement` label alone is present, read the PR/issue body to determine which category applies.
53+
54+
## Items to Exclude
55+
56+
Do not include items in the release notes for:
57+
- Release preparation PRs (e.g. "Prepare release X.Y.Z", version bumps for the release)
58+
- Changelog and release notes PRs themselves
59+
- Individual dependabot/Mend dependency bump PRs (summarize these under Maintenance if there are notable upgrades, otherwise omit)
60+
- PRs that only update license headers, fix typos in code comments, or fix test flakiness with no user-facing impact
61+
- PRs from bots that are purely automated housekeeping
62+
63+
## Items to Consolidate
64+
65+
- When an issue and one or more PRs address the same feature/fix, produce a single release note line referencing the issue (preferred) or the primary PR
66+
- When multiple PRs implement parts of the same feature, consolidate into one line

0 commit comments

Comments
 (0)