From ce9c4bcd53042547cd46d12917683a55062b0167 Mon Sep 17 00:00:00 2001 From: Jeremiah Lowin <153965+jlowin@users.noreply.github.com> Date: Thu, 9 Apr 2026 18:08:57 -0400 Subject: [PATCH] Note generate-notes API in release workflow docs (#3806) --- CLAUDE.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index ac80f2d25..0eed5bedf 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -82,6 +82,16 @@ The handwritten notes are prepended above the auto-generated changelog and are t **Before drafting, always read recent existing releases** (`gh release list` then `gh release view `) to absorb the voice, structure, and level of detail. Each release builds on the tone of previous ones — don't guess at the style from these instructions alone. +**To preview what PRs will be in the release** before it's cut, call the GitHub generate-notes API. This returns the exact auto-generated changelog that `--generate-notes` would append, so you can see the full PR list — useful for picking a pun theme and making sure nothing's been missed: + +```bash +gh api -X POST repos/PrefectHQ/fastmcp/releases/generate-notes \ + -f tag_name=v3.2.3 \ + -f target_commitish=main \ + -f previous_tag_name=v3.2.2 \ + --jq '.body' +``` + **Point releases** (3.0, 3.1, 3.2) get narrative prose: open with the theme of the release, then walk through headline features conceptually — what they enable, why they matter, how they fit together. Write it the way a blog post reads, not a changelog. Multiple paragraphs, code examples where they clarify. **Patch releases** (3.1.1, 3.0.2) get 1-2 sentences explaining what broke and what the fix does. Keep it minimal — the auto-generated changelog has the details.