release

Name: release
Author: backnotprop

7.2kstars517forks

How to install release?

backnotprop/plannotator/release

$npx -y skills add backnotprop/plannotator --skill release

Installs into the current project.

Summary

Prepare and execute a Plannotator release — draft release notes with full contributor credit, bump versions across all package files, build in dependency order, and kick off the tag-driven release pipeline. Use this skill whenever the user mentions preparing a release, bumping ve

Files · 1

View on GitHub

SKILL.md

1	# Plannotator Release
2
3	The process has four phases. Phase 1 (release notes) is where most of the work happens — present the draft for review before proceeding to later phases.
4
5	## Phase 1: Draft Release Notes
6
7	This is the most important phase. The release notes are the public face of each version and the primary way the community sees their contributions recognized.
8
9	### Step 1: Determine scope
10
11	1. Find the latest release tag: `git tag --sort=-v:refname \| head -1`
12	2. Determine the new version number. Ask the user if unclear (patch, minor, or major).
13	3. Gather all changes since the last tag:
14	- `git log --oneline <last-tag>..HEAD` for commit history
15	- `git log --merges --oneline <last-tag>..HEAD` for merged PRs
16	4. For each PR, use `gh pr view <number> --json title,author,body,closedIssues,labels` to get details.
17
18	### Step 2: Research contributors
19
20	This is critical. Every person who participated in the release gets credit — not just PR authors.
21
22	For each PR and linked issue, collect:
23	- PR authors — the person who wrote the code
24	- Issue reporters — who filed the bug or feature request
25	- Issue commenters — who participated in the discussion with useful context
26	- Discussion creators — who started relevant GitHub Discussions
27	- Feature requestors — check the linked "closes #N" issues and their authors
28
29	Use the GitHub API via `gh`:
30	```bash
31	# Get issue details including author
32	gh issue view <number> --json author,title,body
33
34	# Get issue comments to find participants
35	gh api repos/backnotprop/plannotator/issues/<number>/comments --jq '.[].user.login'
36
37	# Get PR review comments
38	gh api repos/backnotprop/plannotator/pulls/<number>/comments --jq '.[].user.login'
39	```
40
41	### Step 3: Write the release notes
42
43	Read the reference release notes in `references/` for the canonical template structure. These are real release notes from previous versions — match their tone, structure, and level of detail.
44
45	- `release-notes-v0.13.0.md` — large release, 14 PRs, 3 first-time contributors, "New Contributors" + narrative "Contributors" section
46	- `release-notes-v0.12.0.md` — large community release, 14 PRs, 10 external, detailed narrative "Contributors" section
47	- `release-notes-v0.13.1.md` — small patch release, 2 PRs, no external authors, "Community" section focused on issue reporters
48
49	Pay attention to how each reference handles contributor crediting differently. Pick the pattern that fits the release's contributor profile — a release with many external PRs warrants a narrative "Contributors" section; a patch driven by issue reports uses a lighter "Community" section.
50
51	Write the file to the repo root as `RELEASE_NOTES_v<VERSION>.md`.
52
53	#### Structure
54
55	1. X/Twitter follow link — first line, always the same:
56	```
57	Follow [@plannotator](https://x.com/plannotator) on X for updates
58	```
59
60	2. "Missed recent releases?" collapsible table — copy from the previous release's notes, then:
61	- Add the previous release (the one you're succeeding) as the newest row
62	- Keep roughly 10-12 rows; drop the oldest if needed
63	- Each row: version link + comma-separated feature highlights (short phrases)
64
65	3. "What's New in vX.Y.Z" — the heart of the notes
66	- Open with 1-3 sentences summarizing the release theme and scope. Mention how many PRs, how many from external contributors, any first-timers.
67	- Each major feature/fix gets its own `###` subsection with:
68	- A descriptive heading (not the PR title verbatim — rephrase for clarity)
69	- 1-4 paragraphs explaining what changed and why it matters. Be specific and concrete. Describe the problem that existed before, what the change does, and how users experience it.
70	- Credit line at the bottom: PR link, linked issues with `closing [#N]`, and contributor attribution
71	- Minor changes go under `### Additional Changes` as bold-titled bullets
72
73	4. Install / Update — standard block, read from the previous release notes and reuse verbatim
74
75	5. "What's Changed" — bullet list of every PR in the release:
76	```
77	- feat: descriptive PR title by @author in [#N](url)
78	```
79
80	6. "New Contributors" — if any first-time contributors:
81	```
82	- @username made their first contribution in [#N](url)
83	```
84
85	7. "Contributors" or "Community" — narrative section recognizing everyone who participated:
86	- PR authors get a sentence about what they built
87	- Issue reporters and commenters get listed with what they reported/discussed

People who liked this also viewed

6 picks

Type

release

7.2kstars517forks

View on GitHub

How to install release?

backnotprop/plannotator/release

$npx -y skills add backnotprop/plannotator --skill release

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Plannotator Release
2
3	The process has four phases. Phase 1 (release notes) is where most of the work happens — present the draft for review before proceeding to later phases.
4
5	## Phase 1: Draft Release Notes
6
7	This is the most important phase. The release notes are the public face of each version and the primary way the community sees their contributions recognized.
8
9	### Step 1: Determine scope
10
11	1. Find the latest release tag: `git tag --sort=-v:refname \| head -1`
12	2. Determine the new version number. Ask the user if unclear (patch, minor, or major).
13	3. Gather all changes since the last tag:
14	- `git log --oneline <last-tag>..HEAD` for commit history
15	- `git log --merges --oneline <last-tag>..HEAD` for merged PRs
16	4. For each PR, use `gh pr view <number> --json title,author,body,closedIssues,labels` to get details.
17
18	### Step 2: Research contributors
19
20	This is critical. Every person who participated in the release gets credit — not just PR authors.
21
22	For each PR and linked issue, collect:
23	- PR authors — the person who wrote the code
24	- Issue reporters — who filed the bug or feature request
25	- Issue commenters — who participated in the discussion with useful context
26	- Discussion creators — who started relevant GitHub Discussions
27	- Feature requestors — check the linked "closes #N" issues and their authors
28
29	Use the GitHub API via `gh`:
30	```bash
31	# Get issue details including author
32	gh issue view <number> --json author,title,body
33
34	# Get issue comments to find participants
35	gh api repos/backnotprop/plannotator/issues/<number>/comments --jq '.[].user.login'
36
37	# Get PR review comments
38	gh api repos/backnotprop/plannotator/pulls/<number>/comments --jq '.[].user.login'
39	```
40
41	### Step 3: Write the release notes
42
43	Read the reference release notes in `references/` for the canonical template structure. These are real release notes from previous versions — match their tone, structure, and level of detail.
44
45	- `release-notes-v0.13.0.md` — large release, 14 PRs, 3 first-time contributors, "New Contributors" + narrative "Contributors" section
46	- `release-notes-v0.12.0.md` — large community release, 14 PRs, 10 external, detailed narrative "Contributors" section
47	- `release-notes-v0.13.1.md` — small patch release, 2 PRs, no external authors, "Community" section focused on issue reporters
48
49	Pay attention to how each reference handles contributor crediting differently. Pick the pattern that fits the release's contributor profile — a release with many external PRs warrants a narrative "Contributors" section; a patch driven by issue reports uses a lighter "Community" section.
50
51	Write the file to the repo root as `RELEASE_NOTES_v<VERSION>.md`.
52
53	#### Structure
54
55	1. X/Twitter follow link — first line, always the same:
56	```
57	Follow [@plannotator](https://x.com/plannotator) on X for updates
58	```
59
60	2. "Missed recent releases?" collapsible table — copy from the previous release's notes, then:
61	- Add the previous release (the one you're succeeding) as the newest row
62	- Keep roughly 10-12 rows; drop the oldest if needed
63	- Each row: version link + comma-separated feature highlights (short phrases)
64
65	3. "What's New in vX.Y.Z" — the heart of the notes
66	- Open with 1-3 sentences summarizing the release theme and scope. Mention how many PRs, how many from external contributors, any first-timers.
67	- Each major feature/fix gets its own `###` subsection with:
68	- A descriptive heading (not the PR title verbatim — rephrase for clarity)
69	- 1-4 paragraphs explaining what changed and why it matters. Be specific and concrete. Describe the problem that existed before, what the change does, and how users experience it.
70	- Credit line at the bottom: PR link, linked issues with `closing [#N]`, and contributor attribution
71	- Minor changes go under `### Additional Changes` as bold-titled bullets
72
73	4. Install / Update — standard block, read from the previous release notes and reuse verbatim
74
75	5. "What's Changed" — bullet list of every PR in the release:
76	```
77	- feat: descriptive PR title by @author in [#N](url)
78	```
79
80	6. "New Contributors" — if any first-time contributors:
81	```
82	- @username made their first contribution in [#N](url)
83	```
84
85	7. "Contributors" or "Community" — narrative section recognizing everyone who participated:
86	- PR authors get a sentence about what they built
87	- Issue reporters and commenters get listed with what they reported/discussed

People who liked this also viewed

6 picks

Type