菜单
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.
| name | release-changelog |
| description | 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. |
Generate the user-facing changelog for the stable Paperclip release.
Paperclip uses calendar versioning (calver):
YYYY.MDD.P (e.g. 2026.318.0)YYYY.MDD.P-canary.N (e.g. 2026.318.1-canary.0)vYYYY.MDD.P for stable, canary/vYYYY.MDD.P-canary.N for canaryThere are no major/minor/patch bumps. The stable version is derived from the intended release date (UTC) plus the next same-day stable patch slot.
Output:
releases/vYYYY.MDD.P.mdImportant rules:
2026.318.1-canary.0, the changelog file stays releases/v2026.318.1.mdBefore generating anything, check whether the file already exists:
ls releases/vYYYY.MDD.P.md 2>/dev/null
If it exists:
Find the last stable tag:
git tag --list 'v*' --sort=-version:refname | head -1
git log v{last}..HEAD --oneline --no-merges
The stable version comes from one of:
./scripts/release.sh stable --date YYYY-MM-DD --print-versiondoc/RELEASING.mdDo not derive the changelog version from a canary tag or prerelease suffix. Do not derive major/minor/patch bumps from API intent — calver uses the date and same-day stable slot.
Collect release data from:
.changeset/*.md filesgh when availableUseful commands:
git log v{last}..HEAD --oneline --no-merges
git log v{last}..HEAD --format="%H %s" --no-merges
ls .changeset/*.md | grep -v README.md
gh pr list --state merged --search "merged:>={last-tag-date}" --json number,title,body,labels
Look for:
BREAKING: or BREAKING CHANGE: commit signalsKey commands:
git diff --name-only v{last}..HEAD -- packages/db/src/migrations/
git diff v{last}..HEAD -- packages/db/src/schema/
git diff v{last}..HEAD -- server/src/routes/ server/src/api/
git log v{last}..HEAD --format="%s" | rg -n 'BREAKING CHANGE|BREAKING:|^[a-z]+!:' || true
If breaking changes are detected, flag them prominently — they must appear in the Breaking Changes section with an upgrade path.
Use these stable changelog sections:
Breaking ChangesHighlightsImprovementsFixesUpgrade Guide when neededExclude purely internal refactors, CI changes, and docs-only work unless they materially affect users.
Guidelines:
When a bullet item clearly maps to a merged pull request, add inline attribution at the end of the entry in this format:
- **Feature name** — Description. ([#123](https://github.com/paperclipai/paperclip/pull/123), @contributor1, @contributor2)
Rules:
Merge pull request #N from user/branch) to map PRs.([#10](url), [#12](url), @user1, @user2).Template:
# vYYYY.MDD.P
> Released: YYYY-MM-DD
## Breaking Changes
## Highlights
## Improvements
## Fixes
## Upgrade Guide
## Contributors
Thank you to everyone who contributed to this release!
@username1, @username2, @username3
Omit empty sections except Highlights, Improvements, and Fixes, which should usually exist.
The Contributors section should always be included. List every person who authored
commits in the release range, @-mentioning them by their GitHub username (not their
real name or email). To find GitHub usernames:
git log v{last}..HEAD --oneline --merges — the branch prefix (e.g. from username/branch) gives the GitHub username.user@users.noreply.github.com, the username is the part before @.gh api users/{guess} or the PR page.Never expose contributor email addresses. Use @username only.
Exclude bot accounts (e.g. lockfile-bot, dependabot) from the list.
Exclude Paperclip founders from the list (e.g. cryppadotta, forgottendev, devinfoley, sockmonster, scotttong)
List contributors in alphabetical order by GitHub username (case-insensitive).
If there are no contributors left after exclusions, then just skip this section and don't mention it.
Before handing it off:
-canary language in the title or filenameThis skill never publishes anything. It only prepares the stable changelog artifact.
Run, verify, reseed, and repair a Paperclip isolated dev workspace service. Use when asked to start or fix a Paperclip project/worktree service and prove that it is managed by the Paperclip runtime, has the full bootstrapped cloned database, is healthy, accepts normal dev credentials, exposes populated app data, and is visible as running from both the control-plane and the served workspace app.
Interact with the Paperclip control plane API to manage tasks, coordinate with other agents, and follow company governance. Use when you need to check assignments, update task status, delegate work, post comments, set up or manage routines (recurring scheduled tasks), or call any Paperclip API endpoint. Do NOT use for the actual domain work itself (writing code, research, etc.) — only for Paperclip coordination.
Run a single Terminal-Bench problem through Paperclip in a bounded, human-in-the-loop improvement cycle until the smoke passes, the board rejects the next fix, the iteration budget is exhausted, or a real blocker is named. Each iteration runs a bounded smoke against an isolated Paperclip App worktree, captures artifacts, diagnoses the exact stop point with `/diagnose-why-work-stopped`, requests board confirmation before any product fix, then reruns against the same worktree. Use whenever an issue asks to "run Terminal-Bench in a loop", "drive Terminal-Bench until it passes", "loop fix-git through Paperclip", or otherwise points at a Terminal-Bench task and asks for bounded iteration with diagnosis.
Developer/maintainer skill for adding a new issue-thread interaction kind to the Paperclip codebase end-to-end: shared contract, server service/routes, UI card, fixtures/Storybook, CLI/MCP/plugin SDK helpers, agent guidance, and tests. Use when a Paperclip contributor is asked to introduce a new interaction family (something analogous to `request_confirmation`, `request_checkbox_confirmation`, `ask_user_questions`, or `suggest_tasks`) or to extend the issue-thread interaction system with a new card type. Do NOT install this on production Paperclip agents — it is for repo work, not agent runtime behavior.
Plan a weekly editorial calendar by mapping company goals to publishable topics, owners, status, and verification notes.
Produce low-fidelity black-and-white UI wireframes as standalone SVG files, optionally bundled into a single-page HTML viewer and published via the here-now skill. Use when the user asks to "wireframe X", "sketch a screen for", "draft a layout", "low-fi mockup", "rough mock", "make a page to view the wireframes", "build a viewer for these screens", or to "deploy / publish / host the wireframes". Do NOT use when the user wants production UI code, branded designs, hi-fi mockups, or animated/interactive prototypes — use frontend-design or similar instead.