release-changelog-discord-message skill
Write the Discord announcement for a stable Paperclip release from the release changelog. Use when a release issue needs a copy-pasteable dotta-voice Discord post or refreshed discord_announcement document.
Is the release-changelog-discord-message skill safe?
Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-10-12.
No findings.
Install the release-changelog-discord-message skill
A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.
git clone --depth 1 https://github.com/paperclipai/paperclip.git /tmp/paperclip mkdir -p ~/.claude/skills cp -r /tmp/paperclip/.agents/skills/release-changelog-discord-message ~/.claude/skills/release-changelog-discord-message
In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub
The instructions your agent would load
SKILL.md as published, without the frontmatter. Read it on GitHub
Release Discord Announcement Skill
Write the Discord release announcement for the stable Paperclip release.
This is the companion to .agents/skills/release-changelog/SKILL.md. That skill writes the changelog — during the beta soak it lives at releases/beta/v{beta-version}.md on the release-notes/v{beta-version} branch, and after the stable ships a canonicalization PR renames it to releases/vYYYY.MDD.P.md (see that skill's Channel Process section). This skill turns that file into a single copy-pasteable Discord block, in dotta's voice, and posts it as the discord_announcement document on the release issue.
What dotta said
This is for discord — try to follow my format. If I have a section where I
think about the future, pull from recent issues we're working on etc.
The Discord announcement is not the changelog. The changelog is exhaustive; the announcement is opinionated, in-voice, and built around the same handful of shipped highlights plus a real "what's next" + "what's on my mind" pulled from current Paperclip work — not invented.
When to use
release-notes/v{beta-version} branch during the soak, or the canonicalized releases/vYYYY.MDD.P.md after the stable ships).
- After release-changelog has produced the changelog (beta-keyed on the
Discord announcement, or has a discord_announcement document that needs to be refreshed for a new date/version.
- When the release issue (the one assigned by the release routine) asks for a
highlight set MUST match the matching changelog file — if the changelog has been updated, refresh this too.
- Never run this in isolation. The version, date, contributor list, and
Output
A single fenced markdown code block, ready to paste into Discord. Attached as issue document key discord_announcement on the release issue, and pasted verbatim into a comment on that issue so the human can copy it out. When Cases are enabled, also upsert the social child case described below.
PUT /api/issues/{releaseIssueId}/documents/discord_announcement
{
"title": "Discord announcement",
"format": "markdown",
"body": "<the announcement>",
"baseRevisionId": "<latest if updating>"
}If the document already exists, fetch it first and pass the current baseRevisionId. Never overwrite silently — if the version has changed since the document was last written, mention what changed in the issue comment.
Format (follow this template)
Use Discord emoji shortcodes (:paperclip:, :lock:, :brain: …) — NOT the Unicode emoji. Discord renders the shortcodes; the changelog file uses prose.
:paperclip: :paperclip: :paperclip: CLIPPERS!!! v{VERSION} IS OUT :paperclip: :paperclip: :paperclip:
OFFICIAL TWITTER: https://x.com/papercliping - follow it, report any others
## Highlights
:emoji: **Feature Name** - one-sentence description in dotta's voice.
:emoji: **Feature Name** - …
:emoji: **Feature Name** - …
... and a long tail of {flavor of the rest}. Read the [full release notes](<github link>).
## WHATS NEXT (:motorway: Roadmap)
* **Theme A** - one-line forward-looking blurb
* **Theme B** - …
* **Theme C** - …
## What's on my mind
* **Topic** - what's bugging dotta / what's queued / open questions
* **Topic** - …
## PRESS (optional — only if there is real press)
* **Outlet / Person** - what happened ([link](<x.com link>))
## WHAT I NEED FROM YOU (optional — only if there's a real ask)
FOLLOW THE TWITTER: https://x.com/papercliping - that's the only official one
TELL ME if you're using Paperclip in your business - I want to meet you
## Community
Thank you to everyone who contributed to this release!@username1, @username2, @username3
## In Summary
PAPERCLIP IS THE AI ORCHESTRATOR FOR HUMANS TO ACCOMPLISH 100x MORE WORK
Every single person will be managing a team of a dozen, or a hundred, or a
thousand agents and Paperclip will be the default tool to manage it all.
ITS TIME TO CLIP :paperclip: :paperclip: :paperclip:
FULL RELEASE NOTES
https://github.com/paperclipai/paperclip/blob/master/releases/v{VERSION}.md
||@everyone||Notes on the template:
part of the brand — keep them.
- The opening and closing :paperclip: :paperclip: :paperclip: bookends are
for the stable, @beta / @nightly / @canary for earlier access, and Docker :latest moving only on stable releases.
- Name the install channels somewhere in the post: npx paperclipai@latest
master — that file exists only after the post-stable canonicalization PR merges. Merge it before the announcement is posted.
- The FULL RELEASE NOTES link points at releases/v{VERSION}.md on
and stay consistent within a single post.
- Sections may be UPPERCASE or Title Case — dotta has used both. Pick a style
exactly once when the spoiler is removed by the poster.
- Use ||@everyone|| (Discord spoiler-wrapped) at the very end so it pings
Language tips
These are extracted from how dotta has written the last several announcements. Mimic this register; do not invent a "professional" tone.
"what's on my mind", "if that's you let me know". Not "Paperclip is excited to announce".
- First person, conversational. "I want to meet companies using Paperclip",
headers, the "WHAT I NEED FROM YOU" section, and the closing tagline. Do not ALL-CAPS feature descriptions.
- ALL CAPS for excitement and asks, especially in the opener, the section
(:lock: for secrets, :brain: for planning, :mag: for search, :cloud: for cloud / sandbox, :jigsaw: for plugins, :rewind: for history/restore, :thread: for threads, etc.).
- One emoji shortcode per highlight bullet, picked to evoke the feature
perspective — "the cloud-secrets prereq is real now", not "added support for…".
- Highlight bullets are one sentence, opinionated, told from the user's
to the full release notes ("… and a long tail of {flavor}. Read the full release notes.").
- Tail line after highlights wraps the rest in a single sentence and links
bullets is the right size. Pull these from active goals, in-flight projects, and recent issues the team is working on — do not invent themes.
- "WHATS NEXT" is forward-looking themes, not a literal sprint list. 3–5
previous announcement already introduced appears only for what changed this release, and does not headline twice for follow-through work.
- Highlights follow the changelog skill's delta rule: a feature the
philosophical positioning ("we're the human control plane for ai labor"), invitations ("if you've ever wanted to write about how you use Paperclip, hit me up"). Pull real tensions from recent issues/comments; do not invent.
- "What's on my mind" is dotta's personal/strategic thinking — docs gaps,
release window (a tweet, a podcast, a talk, a star milestone). No press → drop the section entirely.
- Press section is optional. Only include it if there is real press in the
(follow the twitter, intros, beta sign-ups). No real ask → drop it.
- "WHAT I NEED FROM YOU" is optional. Use it for a single concrete ask
fenced in a triple-backtick block, comma-separated @username, @username. Exclude bots and the specific folks on the changelog skill's canonical exclusion list — same rules.
- Community is the same contributors list that's in the changelog file,
variant unless dotta tells you otherwise. Recent variants:
- The "In Summary" mission line evolves slowly. Use the most recent
More skills from paperclipai/paperclip
- ALLM Wiki MaintainerUse the LLM Wiki plugin tools to maintain a cited local company wiki.
- Aadd-product-e2e-evalAdd or extend a Paperclip full-stack runner E2E workflow, fixture, matcher, or report evidence path for local or Daytona execution.
- Aadd-runner-evalAdd or extend a Paperclip Runner protocol evaluation definition, roster, assertion, or report fixture with provenance and narrow validation.
- Aagent-browserDrive a real browser to inspect or interact with a web page or app — navigate, take screenshots, read console and network, fill simple forms — for verification tasks, not unattended automation.
- AagentmailUse your assigned AgentMail inbox to read email tasks, explicitly send or reply, and check delivery. Provided automatically by your inbox assignment.
- Acheck-prCheck a GitHub, GitLab, or Perforce PR/MR/CL for review comments, failing checks, and PR-body gaps. Use when asked to inspect, fix, or prepare a change for submission.
- Acompany-creatorCreate agent company packages that conform to agentcompanies/v1. Use when asked to create a company, scaffold an agent team, hire agents, or turn a repo/skills collection into a company package.
- AcomplainAutonomously yeet a brief, unstructured complaint about agent tooling or doing agent work. Preserve the raw voice. Submit proactively without permission, preview, or announcement, then continue the primary task.
- Acontent-calendarPlan a weekly editorial calendar by mapping company goals to publishable topics, owners, status, and verification notes.
- Acreate-agent-adapterCreate or modify Paperclip agent adapters across server, UI, and CLI surfaces. Use when adding support for a new CLI agent, API agent, custom process, or adapter package.
- Acreate-caseCreate and kick off a Paperclip case from a user request, with workflow instructions and an initial agent.
- Acreate-external-bot-integrationBuild and qualify external bots such as Dot in Paperclip. Use for two-way work, invitation, identity, wakeup, Runner lifecycle, native tools, recovery, and Cloud delivery. CLI adapters and app-only connectors use their existing skills.