Skip to content

feat(cutting-releases): add release highlights step #3382

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ralphbean merged 1 commit into from
Jul 8, 2026
+45 −1
Merged

feat(cutting-releases): add release highlights step #3382

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
46 changes: 45 additions & 1 deletion skills/cutting-releases/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -114,7 +114,51 @@ gh run list --workflow=release.yml --limit=1
Read [post-flight.md](post-flight.md) in this skill's directory and
follow the post-flight verification procedure.

### 9. Install the binary locally
### 9. Write release highlights

After post-flight confirms the release is published, write a short user-facing
summary highlighting the changes that matter most to end users.

1. **Gather the raw changelog.** Run `gh release view <tag> --json body -q .body`
to get the auto-generated release body.
2. **Research the actual changes.** Do not rely on PR titles or one-line
summaries — they often undersell or misrepresent user impact. Launch an
`Agent` sub-agent to read the full body, diff, and comments of every merged
PR in the release (`gh pr view <number>`, `gh pr diff <number>`). The agent
should identify which changes affect user-visible behavior, CLI flags,
configuration, error messages, performance, or compatibility — and flag
anything that looks like a breaking change or notable upgrade, even if the
PR title doesn't say so.
3. **Draft highlights.** Write one or more paragraphs of prose (not
bullet lists — use only one paragraph if only one is necessary)
focusing on *what changed for the user*, not internal refactors.
Bold the names of features or areas being discussed (e.g. **token mint**,
**`fullsend init`**). Use code fences where showing a command or config
snippet helps illustrate a change. Skip items that have no user-visible
effect. Full coverage of every change is a non-goal — clarity and impact
are the goals.
4. **Present the draft to the user.** Use `AskUserQuestion` to show the
proposed highlights text and ask:

> Here are the draft release highlights I'd prepend to the release body.
> Edit freely or say "looks good" to proceed.
5. **Prepend to the release.** Once confirmed (with any edits applied), fetch
the current release body, prepend the highlights separated by a horizontal
rule (`---`), and update the release:

```
gh release edit <tag> --notes "$(cat <<'EOF'
<highlights>
---
<existing body>
EOF
)"
Comment on lines +150 to +158

@qodo-code-review qodo-code-review Bot Jul 7, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remediation recommended

1. Indented heredoc terminator 🐞 Bug ≡ Correctness

The Step 9 example for gh release edit indents the heredoc terminator (EOF) inside a
list-indented fenced block, so a literal copy/paste will not terminate the heredoc and will wait for
more input. This can block the new “prepend highlights” step at the final release-update command.
Agent Prompt 
### Issue description
The Step 9 snippet uses a heredoc within a list-indented fenced code block. In the markdown source, every line (including the `EOF` terminator) is indented, which makes the heredoc terminator not match when the command is run as written, causing the shell to keep waiting for input.

### Issue Context
This is user-facing operational guidance intended to be run during the release process; the example should be safe to copy/paste and execute.

### Fix Focus Areas
- skills/cutting-releases/SKILL.md[150-159]

### Suggested fix approaches
Choose one:
1. Move the fenced code block out of the nested list so `EOF` can be flush-left.
2. Avoid heredocs here and use a temp file + `gh release edit ... --notes-file <path>` (or an equivalent approach already used in this repo).
3. If you must keep it nested, rewrite the snippet so the terminator is guaranteed to be at column 0 in the rendered/output command (not indented in the literal text).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

```

### 10. Install the binary locally

Use `AskUserQuestion` to ask where to install (default: `~/.local/bin/`),
then run the install script using its repo-root-relative path:
Expand Down
Loading