Skip to content

fix(release-notes): filter stale release PRs #96

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
chenjiahan merged 1 commit into from
Jul 24, 2026
Merged

fix(release-notes): filter stale release PRs #96

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
8 changes: 5 additions & 3 deletions .agents/skills/create-draft-release-notes/SKILL.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,7 +9,7 @@ metadata:

## Overview

Create a GitHub draft release when possible, organize the generated notes by conventional commit type, and save the organized body back to the draft. If `gh` cannot create or edit the draft, return the organized Markdown in the conversation with manual creation steps. Preserve each release note item exactly; only split accidentally joined bullets, move bullets into sections, and adjust headings. Add a top `## Highlights` section only when the user explicitly asks for highlights.
Create a GitHub draft release when possible, organize the generated notes by conventional commit type, and save the organized body back to the draft. If `gh` cannot create or edit the draft, return the organized Markdown in the conversation with manual creation steps. Preserve each release note item exactly except stale release PRs; otherwise only split accidentally joined bullets, move bullets into sections, and adjust headings. Add a top `## Highlights` section only when the user explicitly asks for highlights.

## Security Notes

Expand Down Expand Up @@ -138,7 +138,7 @@ Use this when the user provides generated release note Markdown and only wants i
node .agents/skills/create-draft-release-notes/scripts/create-draft-release-notes.mjs release-notes.md
```

Omit the file path to read from stdin. Review that every original item still appears once and non-item sections remain.
Omit the file path to read from stdin. Review that every retained item appears once and non-item sections remain.

## Optional Highlights Workflow

Expand All @@ -154,7 +154,7 @@ Write highlights before `## What's Changed`:
- Use one `###` heading per highlight.
- Keep each highlight to a short paragraph plus an optional fenced code example.
- Include examples only when the API/configuration is clear.
- Do not rewrite or reorder changelog items below `## What's Changed`.
- Do not rewrite or reorder retained changelog items below `## What's Changed`.
- Replace an existing top `## Highlights` block instead of adding another one.

Example shape:
Expand Down Expand Up @@ -203,6 +203,8 @@ Keep each category in generated top-to-bottom order.

## Preservation Rules

- Remove bullets that clearly identify a release PR for `$previous_tag` or an older published version, such as `release: v1.0.0` in `v1.0.1` notes; keep current-version and ambiguous items.

@chatgpt-codex-connector chatgpt-codex-connector Bot Jul 24, 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.

P2 Badge Require tag context before filtering Markdown-only notes

When the Markdown-Only workflow is used, neither release_tag nor previous_tag is collected, so the supplied Markdown alone cannot establish whether a bullet such as release: v1.0.0 is stale or is the release currently being prepared. Applying this global removal rule to that workflow can therefore silently delete a valid current-release PR; limit filtering to workflows with a known release range, or require the tag/range as Markdown-Only input.

Useful? React with 👍 / 👎.

- If anything is removed, list the original bullets verbatim for the user outside the release note body.
- Do not rewrite bullet text, authors, URLs, PR numbers, package names, scopes, punctuation, or casing.
- Do not drop comments, `**Full Changelog**`, or other non-item sections.
- Do not add commentary to the release note itself, except for a requested `## Highlights` section.
Expand Down