release-announcement

Name: release-announcement
Author: getpaperclipai

5stars1forks

How to install release-announcement?

getpaperclipai/paperclip/release-announcement

$npx -y skills add getpaperclipai/paperclip --skill release-announcement

Installs into the current project.

Summary

Write a release announcement — changelog, blog post, in-app note, or social post — that leads with user impact, names the audience, and includes upgrade/migration steps without filler.

Files · 1

View on GitHub

SKILL.md

1	# Release Announcement
2
3	Write the channel-appropriate announcement for a release without churn. Different surfaces need different shapes: a changelog entry is not a blog post is not a social card. The bar is: a reader of the chosen surface can decide in under 30 seconds whether this release affects them, and if so what to do.
4
5	## When to use
6
7	- A version, feature, or fix is shipping and needs writeup for at least one surface.
8	- A previously private feature is going GA.
9	- A breaking change needs broadcast before users hit it.
10
11	## When not to use
12
13	- An internal-only change with no user impact. Update internal docs; do not announce.
14	- The release is incomplete (still in active development). Wait until it ships, even if marketing wants the post.
15
16	## Determine the audience and channel first
17
18	\| Audience \| Best channel \| Tone \|
19	\|---\|---\|---\|
20	\| Existing power users \| Changelog, in-app note \| Terse, factual, links \|
21	\| Engineering teams adopting your API \| Release notes, dev blog \| Examples, migration steps, version pins \|
22	\| Prospective customers \| Landing page, marketing blog \| Story arc, problem → solution, social proof \|
23	\| Broad audience \| Social post, email newsletter \| One-sentence pitch, link to depth \|
24	\| Internal team \| Slack/Discord post \| What changed, who to ping if it breaks \|
25
26	Pick the audience for this writeup. One release often needs several writeups; do not blend them.
27
28	## Universal structure
29
30	Whatever the channel, lead with:
31
32	1. What changed. One sentence in the user's vocabulary.
33	2. Who it affects. Which user role / use case.
34	3. What to do. Migrate now / opt-in / no action needed.
35
36	Everything else is depth that supports those three.
37
38	## Channel templates
39
40	### Changelog entry (terse)
41
42	```md
43	## v1.42.0 — 2026-05-26
44
45	### Added
46	- <feature> — <one-line user benefit>. ([#1234](link))
47
48	### Changed
49	- <change> — <one-line impact>. ([#1235](link))
50
51	### Fixed
52	- <bug> — <one-line user-visible symptom>. ([#1236](link))
53
54	### Deprecated
55	- <thing>. Replaced by <thing>. Removal planned for v<x>.
56
57	### Breaking
58	- <change>. Migration: <one-line> or <link to guide>.
59	```
60
61	### Release notes (for adopters)
62
63	Same as changelog, plus:
64
65	- Migration guide section with before/after code.
66	- Compatibility table (versions, runtimes, OS).
67	- Known issues and workarounds.
68	- Acknowledgements (contributors, reporters of fixed bugs).
69
70	### Dev blog post (300–800 words)
71
72	- Hook (1 paragraph): the problem the release solves, in a real-world scenario.
73	- What's new (3–5 bullets with sub-paragraphs): features, with one code or screenshot example each.
74	- Upgrade (1 paragraph): how to upgrade, what to check.
75	- What's next: one sentence about the next direction. Avoid promises.
76
77	### In-app note
78
79	- 1 sentence.
80	- 1 link.
81	- Dismiss after seen.
82
83	### Social post
84
85	- 1 sentence pitch.
86	- 1 link.
87	- 1 image or short clip.
88	- No threadbait. If it needs a thread, write a blog post instead.
89
90	## Writing rules
91
92	- Lead with the user, not the team. `You can now export to CSV` beats `We've added CSV export`.
93	- Numbers beat adjectives. `60% faster cold start` beats `much faster`. Cite the methodology.
94	- Show, don't just tell. One code snippet, one screenshot — more is noise.
95	- Date the post. Undated release content rots fastest.
96	- Link the migration path explicitly. Do not bury it.
97	- Mark breaking changes with `Breaking:` prefix. Repeat in the email/social channel.
98
99	## Avoid
100
101	- "We are excited to announce" filler.
102	- Lists of changes that mix user-visible and internal items.
103	- Marketing claims without a way to verify.
104	- Promised dates for unshipped work.
105	- Pre-announcing something the team has not yet committed to ship.
106
107	## Post-publish checklist
108
109	- Changelog is in source control alongside the release.
110	- Blog post date matches actual ship date.
111	- All links work (release tag, PRs, docs sections).
112	- Breaking changes are also in the upgrade guide, not only the post.
113	- Internal team is notified before the public post goes live, not after.

People who liked this also viewed

6 picks

Type

release-announcement

5stars1forks

View on GitHub

How to install release-announcement?

getpaperclipai/paperclip/release-announcement

$npx -y skills add getpaperclipai/paperclip --skill release-announcement

Installs into the current project.

Summary

Write a release announcement — changelog, blog post, in-app note, or social post — that leads with user impact, names the audience, and includes upgrade/migration steps without filler.

Files · 1

View on GitHub

SKILL.md

1	# Release Announcement
2
3	Write the channel-appropriate announcement for a release without churn. Different surfaces need different shapes: a changelog entry is not a blog post is not a social card. The bar is: a reader of the chosen surface can decide in under 30 seconds whether this release affects them, and if so what to do.
4
5	## When to use
6
7	- A version, feature, or fix is shipping and needs writeup for at least one surface.
8	- A previously private feature is going GA.
9	- A breaking change needs broadcast before users hit it.
10
11	## When not to use
12
13	- An internal-only change with no user impact. Update internal docs; do not announce.
14	- The release is incomplete (still in active development). Wait until it ships, even if marketing wants the post.
15
16	## Determine the audience and channel first
17
18	\| Audience \| Best channel \| Tone \|
19	\|---\|---\|---\|
20	\| Existing power users \| Changelog, in-app note \| Terse, factual, links \|
21	\| Engineering teams adopting your API \| Release notes, dev blog \| Examples, migration steps, version pins \|
22	\| Prospective customers \| Landing page, marketing blog \| Story arc, problem → solution, social proof \|
23	\| Broad audience \| Social post, email newsletter \| One-sentence pitch, link to depth \|
24	\| Internal team \| Slack/Discord post \| What changed, who to ping if it breaks \|
25
26	Pick the audience for this writeup. One release often needs several writeups; do not blend them.
27
28	## Universal structure
29
30	Whatever the channel, lead with:
31
32	1. What changed. One sentence in the user's vocabulary.
33	2. Who it affects. Which user role / use case.
34	3. What to do. Migrate now / opt-in / no action needed.
35
36	Everything else is depth that supports those three.
37
38	## Channel templates
39
40	### Changelog entry (terse)
41
42	```md
43	## v1.42.0 — 2026-05-26
44
45	### Added
46	- <feature> — <one-line user benefit>. ([#1234](link))
47
48	### Changed
49	- <change> — <one-line impact>. ([#1235](link))
50
51	### Fixed
52	- <bug> — <one-line user-visible symptom>. ([#1236](link))
53
54	### Deprecated
55	- <thing>. Replaced by <thing>. Removal planned for v<x>.
56
57	### Breaking
58	- <change>. Migration: <one-line> or <link to guide>.
59	```
60
61	### Release notes (for adopters)
62
63	Same as changelog, plus:
64
65	- Migration guide section with before/after code.
66	- Compatibility table (versions, runtimes, OS).
67	- Known issues and workarounds.
68	- Acknowledgements (contributors, reporters of fixed bugs).
69
70	### Dev blog post (300–800 words)
71
72	- Hook (1 paragraph): the problem the release solves, in a real-world scenario.
73	- What's new (3–5 bullets with sub-paragraphs): features, with one code or screenshot example each.
74	- Upgrade (1 paragraph): how to upgrade, what to check.
75	- What's next: one sentence about the next direction. Avoid promises.
76
77	### In-app note
78
79	- 1 sentence.
80	- 1 link.
81	- Dismiss after seen.
82
83	### Social post
84
85	- 1 sentence pitch.
86	- 1 link.
87	- 1 image or short clip.
88	- No threadbait. If it needs a thread, write a blog post instead.
89
90	## Writing rules
91
92	- Lead with the user, not the team. `You can now export to CSV` beats `We've added CSV export`.
93	- Numbers beat adjectives. `60% faster cold start` beats `much faster`. Cite the methodology.
94	- Show, don't just tell. One code snippet, one screenshot — more is noise.
95	- Date the post. Undated release content rots fastest.
96	- Link the migration path explicitly. Do not bury it.
97	- Mark breaking changes with `Breaking:` prefix. Repeat in the email/social channel.
98
99	## Avoid
100
101	- "We are excited to announce" filler.
102	- Lists of changes that mix user-visible and internal items.
103	- Marketing claims without a way to verify.
104	- Promised dates for unshipped work.
105	- Pre-announcing something the team has not yet committed to ship.
106
107	## Post-publish checklist
108
109	- Changelog is in source control alongside the release.
110	- Blog post date matches actual ship date.
111	- All links work (release tag, PRs, docs sections).
112	- Breaking changes are also in the upgrade guide, not only the post.
113	- Internal team is notified before the public post goes live, not after.

People who liked this also viewed

6 picks

Type