release-changelog

Name: release-changelog
Author: IncomeStreamSurfer

69stars33forks

How to install release-changelog?

incomestreamsurfer/paperclip-surfers/release-changelog

$npx -y skills add IncomeStreamSurfer/paperclip-surfers --skill release-changelog

Installs into the current project.

Summary

Generate the stable Paperclip release changelog at releases/vYYYY.MDD.P.md by reading commits, changesets, and merged PR context since the last stable tag.

Files · 1

View on GitHub

SKILL.md

1	# Release Changelog Skill
2
3	Generate the user-facing changelog for the stable Paperclip release.
4
5	## Versioning Model
6
7	Paperclip uses calendar versioning (calver):
8
9	- Stable releases: `YYYY.MDD.P` (e.g. `2026.318.0`)
10	- Canary releases: `YYYY.MDD.P-canary.N` (e.g. `2026.318.1-canary.0`)
11	- Git tags: `vYYYY.MDD.P` for stable, `canary/vYYYY.MDD.P-canary.N` for canary
12
13	There are no major/minor/patch bumps. The stable version is derived from the
14	intended release date (UTC) plus the next same-day stable patch slot.
15
16	Output:
17
18	- `releases/vYYYY.MDD.P.md`
19
20	Important rules:
21
22	- even if there are canary releases such as `2026.318.1-canary.0`, the changelog file stays `releases/v2026.318.1.md`
23	- do not derive versions from semver bump types
24	- do not create canary changelog files
25
26	## Step 0 — Idempotency Check
27
28	Before generating anything, check whether the file already exists:
29
30	```bash
31	ls releases/vYYYY.MDD.P.md 2>/dev/null
32	```
33
34	If it exists:
35
36	1. read it first
37	2. present it to the reviewer
38	3. ask whether to keep it, regenerate it, or update specific sections
39	4. never overwrite it silently
40
41	## Step 1 — Determine the Stable Range
42
43	Find the last stable tag:
44
45	```bash
46	git tag --list 'v*' --sort=-version:refname \| head -1
47	git log v{last}..HEAD --oneline --no-merges
48	```
49
50	The stable version comes from one of:
51
52	- an explicit maintainer request
53	- `./scripts/release.sh stable --date YYYY-MM-DD --print-version`
54	- the release plan already agreed in `doc/RELEASING.md`
55
56	Do not derive the changelog version from a canary tag or prerelease suffix.
57	Do not derive major/minor/patch bumps from API intent — calver uses the date and same-day stable slot.
58
59	## Step 2 — Gather the Raw Inputs
60
61	Collect release data from:
62
63	1. git commits since the last stable tag
64	2. `.changeset/*.md` files
65	3. merged PRs via `gh` when available
66
67	Useful commands:
68
69	```bash
70	git log v{last}..HEAD --oneline --no-merges
71	git log v{last}..HEAD --format="%H %s" --no-merges
72	ls .changeset/*.md \| grep -v README.md
73	gh pr list --state merged --search "merged:>={last-tag-date}" --json number,title,body,labels
74	```
75
76	## Step 3 — Detect Breaking Changes
77
78	Look for:
79
80	- destructive migrations
81	- removed or changed API fields/endpoints
82	- renamed or removed config keys
83	- `BREAKING:` or `BREAKING CHANGE:` commit signals
84
85	Key commands:
86
87	```bash
88	git diff --name-only v{last}..HEAD -- packages/db/src/migrations/
89	git diff v{last}..HEAD -- packages/db/src/schema/
90	git diff v{last}..HEAD -- server/src/routes/ server/src/api/
91	git log v{last}..HEAD --format="%s" \| rg -n 'BREAKING CHANGE\|BREAKING:\|^[a-z]+!:' \|\| true
92	```
93
94	If breaking changes are detected, flag them prominently — they must appear in the
95	Breaking Changes section with an upgrade path.
96
97	## Step 4 — Categorize for Users
98
99	Use these stable changelog sections:
100
101	- `Breaking Changes`
102	- `Highlights`
103	- `Improvements`
104	- `Fixes`
105	- `Upgrade Guide` when needed
106
107	Exclude purely internal refactors, CI changes, and docs-only work unless they materially affect users.
108
109	Guidelines:
110
111	- group related commits into one user-facing entry
112	- write from the user perspective
113	- keep highlights short and concrete
114	- spell out upgrade actions for breaking changes
115
116	### Inline PR and contributor attribution
117
118	When a bullet item clearly maps to a merged pull request, add inline attribution at the
119	end of the entry in this format:
120
121	```
122	- Feature name — Description. ([#123](https://github.com/paperclipai/paperclip/pull/123), @contributor1, @contributor2)
123	```
124
125	Rules:
126
127	- Only add a PR link when you can confidently trace the bullet to a specific merged PR.
128	Use merge commit messages (`Merge pull request #N from user/branch`) to map PRs.
129	- List the contributor(s) who authored the PR. Use GitHub usernames, not real names or emails.
130	- If multiple PRs contributed to a single bullet, list them all: `([#10](url), [#12](url), @user1, @user2)`.
131	- If you cannot determine the PR number or contributor with confidence, omit the attribution
132	parenthetical — do not guess.
133	- Core maintainer commits that don't have an external PR can omit the parenthetical.
134
135	## Step 5 — Write the File
136
137	Template:
138
139	```markdown
140	# vYYYY.MDD.P
141
142	> Released: YYYY-MM-DD
143
144	## Breaking Changes
145
146	## Highlights
147
148	## Improvements
149
150	## Fixes
151
152	## Upgrade Guide
153
154	## Contributors
155
156	Thank you to everyone who contributed to this release!
157
158	@username1, @username2, @username3
159	```
160
161	Omit empty sections except `Highlights`, `Improvements`, and `Fixes`, which should usually exist.
162
163	The `Contributors` section should always be included. List every person who authored
164	commits in the release range, @-mentioning them by their GitHub username (not their
165	real name or email). To find GitHub usernames:
166
167	1. Extract usernames from merge commit messages: `git log v{last}..HEAD --oneline --merges` — the branch prefix (e.g. `from username/br

People who liked this also viewed

6 picks

Type

grill-with-docsA relentless interview to sharpen a plan or design, which also creates docs (ADR's and glossary) as we go.SkillsJul 2026537k182k
lark-minutes飞书妙记：搜索妙记、查看妙记基础信息、下载/上传音视频、读取或编辑妙记的产物内容、改标题、替换说话人/关键词、申请妙记查看/编辑权限。当给出minute_token、本地音视频文件，要查/改/转妙记产物，或用户明确要主动申请妙记权限时使用；本地音视频转纪要/逐字稿优先走本 skill，不要用 ffmpeg/whisper 本地转写。不负责：获取会议关联妙记，或仅按自然语言标题定位纪要SkillsJul 2026379k16k
lark-markdown飞书 Markdown：查看、创建、上传、编辑和比较 Markdown 文件。当用户需要创建或编辑 Markdown 文件、读取、修改、局部 patch 或比较差异时使用。不负责将 Markdown 导入为飞书在线文档，也不负责文件搜索、权限、评论、移动、删除等云空间管理操作。SkillsJul 2026295k16k
docxUse this skill whenever the user wants to create, read, edit, or manipulate Word documents (.docx files) or Word templates (.dotx files). Triggers include: any mention of 'Word doc', 'word document', SkillsJul 2026157k163k
edit-articleSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026154k181k
lark-note飞书会议纪要（Note）直查：已知 note_id 时查询纪要详情、展示类型、关联文档 token，并读取 unified 原始逐字记录。当用户已持有 note_id，或从文档显式 vc-node-id 获得 note_id 时使用。不负责会议/日程/妙记定位、文档标题搜索或 Docx 正文读取。SkillsJul 2026154k16k

release-changelog

69stars33forks

View on GitHub

How to install release-changelog?

incomestreamsurfer/paperclip-surfers/release-changelog

$npx -y skills add IncomeStreamSurfer/paperclip-surfers --skill release-changelog

Installs into the current project.

Summary

Generate the stable Paperclip release changelog at releases/vYYYY.MDD.P.md by reading commits, changesets, and merged PR context since the last stable tag.

Files · 1

View on GitHub

SKILL.md

1	# Release Changelog Skill
2
3	Generate the user-facing changelog for the stable Paperclip release.
4
5	## Versioning Model
6
7	Paperclip uses calendar versioning (calver):
8
9	- Stable releases: `YYYY.MDD.P` (e.g. `2026.318.0`)
10	- Canary releases: `YYYY.MDD.P-canary.N` (e.g. `2026.318.1-canary.0`)
11	- Git tags: `vYYYY.MDD.P` for stable, `canary/vYYYY.MDD.P-canary.N` for canary
12
13	There are no major/minor/patch bumps. The stable version is derived from the
14	intended release date (UTC) plus the next same-day stable patch slot.
15
16	Output:
17
18	- `releases/vYYYY.MDD.P.md`
19
20	Important rules:
21
22	- even if there are canary releases such as `2026.318.1-canary.0`, the changelog file stays `releases/v2026.318.1.md`
23	- do not derive versions from semver bump types
24	- do not create canary changelog files
25
26	## Step 0 — Idempotency Check
27
28	Before generating anything, check whether the file already exists:
29
30	```bash
31	ls releases/vYYYY.MDD.P.md 2>/dev/null
32	```
33
34	If it exists:
35
36	1. read it first
37	2. present it to the reviewer
38	3. ask whether to keep it, regenerate it, or update specific sections
39	4. never overwrite it silently
40
41	## Step 1 — Determine the Stable Range
42
43	Find the last stable tag:
44
45	```bash
46	git tag --list 'v*' --sort=-version:refname \| head -1
47	git log v{last}..HEAD --oneline --no-merges
48	```
49
50	The stable version comes from one of:
51
52	- an explicit maintainer request
53	- `./scripts/release.sh stable --date YYYY-MM-DD --print-version`
54	- the release plan already agreed in `doc/RELEASING.md`
55
56	Do not derive the changelog version from a canary tag or prerelease suffix.
57	Do not derive major/minor/patch bumps from API intent — calver uses the date and same-day stable slot.
58
59	## Step 2 — Gather the Raw Inputs
60
61	Collect release data from:
62
63	1. git commits since the last stable tag
64	2. `.changeset/*.md` files
65	3. merged PRs via `gh` when available
66
67	Useful commands:
68
69	```bash
70	git log v{last}..HEAD --oneline --no-merges
71	git log v{last}..HEAD --format="%H %s" --no-merges
72	ls .changeset/*.md \| grep -v README.md
73	gh pr list --state merged --search "merged:>={last-tag-date}" --json number,title,body,labels
74	```
75
76	## Step 3 — Detect Breaking Changes
77
78	Look for:
79
80	- destructive migrations
81	- removed or changed API fields/endpoints
82	- renamed or removed config keys
83	- `BREAKING:` or `BREAKING CHANGE:` commit signals
84
85	Key commands:
86
87	```bash
88	git diff --name-only v{last}..HEAD -- packages/db/src/migrations/
89	git diff v{last}..HEAD -- packages/db/src/schema/
90	git diff v{last}..HEAD -- server/src/routes/ server/src/api/
91	git log v{last}..HEAD --format="%s" \| rg -n 'BREAKING CHANGE\|BREAKING:\|^[a-z]+!:' \|\| true
92	```
93
94	If breaking changes are detected, flag them prominently — they must appear in the
95	Breaking Changes section with an upgrade path.
96
97	## Step 4 — Categorize for Users
98
99	Use these stable changelog sections:
100
101	- `Breaking Changes`
102	- `Highlights`
103	- `Improvements`
104	- `Fixes`
105	- `Upgrade Guide` when needed
106
107	Exclude purely internal refactors, CI changes, and docs-only work unless they materially affect users.
108
109	Guidelines:
110
111	- group related commits into one user-facing entry
112	- write from the user perspective
113	- keep highlights short and concrete
114	- spell out upgrade actions for breaking changes
115
116	### Inline PR and contributor attribution
117
118	When a bullet item clearly maps to a merged pull request, add inline attribution at the
119	end of the entry in this format:
120
121	```
122	- Feature name — Description. ([#123](https://github.com/paperclipai/paperclip/pull/123), @contributor1, @contributor2)
123	```
124
125	Rules:
126
127	- Only add a PR link when you can confidently trace the bullet to a specific merged PR.
128	Use merge commit messages (`Merge pull request #N from user/branch`) to map PRs.
129	- List the contributor(s) who authored the PR. Use GitHub usernames, not real names or emails.
130	- If multiple PRs contributed to a single bullet, list them all: `([#10](url), [#12](url), @user1, @user2)`.
131	- If you cannot determine the PR number or contributor with confidence, omit the attribution
132	parenthetical — do not guess.
133	- Core maintainer commits that don't have an external PR can omit the parenthetical.
134
135	## Step 5 — Write the File
136
137	Template:
138
139	```markdown
140	# vYYYY.MDD.P
141
142	> Released: YYYY-MM-DD
143
144	## Breaking Changes
145
146	## Highlights
147
148	## Improvements
149
150	## Fixes
151
152	## Upgrade Guide
153
154	## Contributors
155
156	Thank you to everyone who contributed to this release!
157
158	@username1, @username2, @username3
159	```
160
161	Omit empty sections except `Highlights`, `Improvements`, and `Fixes`, which should usually exist.
162
163	The `Contributors` section should always be included. List every person who authored
164	commits in the release range, @-mentioning them by their GitHub username (not their
165	real name or email). To find GitHub usernames:
166
167	1. Extract usernames from merge commit messages: `git log v{last}..HEAD --oneline --merges` — the branch prefix (e.g. `from username/br

People who liked this also viewed

6 picks

Type