release

Coordinates Paperclip stable releases across npm publishing, GitHub Releases, smoke testing, and announcement follow-up.

Updated Jun 16, 2026
One-click install
npx skills add https://github.com/adamtpang/summon.company --skill release-adamtpang
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: release
Source: https://github.com/adamtpang/summon.company/tree/main/.agents/skills/release
Command: npx skills add https://github.com/adamtpang/summon.company --skill release-adamtpang

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Shipping a stable Paperclip release involves many coordinated steps—changelog drafting, canary validation, smoke testing, npm promotion, GitHub Release creation, and announcement follow-up—and missing any one of them leaves the release incomplete or broken. This Skill orchestrates the entire maintainer release workflow so nothing is skipped. ## Core Features & Use Cases - End-to-End Release Orchestration: Walks through candidate selection, changelog drafting via the release-changelog skill, verification gates, canary validation, Docker smoke testing, and stable promotion. - Commit-Driven Versioning: Enforces the YYYY.MDD.P versioning model where canaries publish automatically from master and stable releases are manually promoted from a tested source ref. - Release-Content Case Tracking: Creates a deterministic parent release case with blog_post and tweet_storm child cases via the Paperclip Cases API for announcement follow-up. - Use Case: When leadership says "ship the release," use this Skill to verify the latest canary, smoke test it with docker-onboard-smoke.sh, promote it to stable via the release workflow, and create the GitHub Release and announcement cases. ## Quick Start Ask the agent to ship the stable Paperclip release from the latest verified canary on master.

Frequently Asked Questions about release

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I promote a Paperclip canary to a stable release?

Choose the tested source ref, resolve the target version with ./scripts/release.sh stable --date YYYY-MM-DD --print-version, then run the release workflow via workflow_dispatch with source_ref, stable_date, and dry_run inputs. Run a dry-run first, then the live publish.

How does Paperclip versioning work for canary and stable releases?

Every push to master publishes a canary automatically using YYYY.MDD.P-canary.N. Stable releases use YYYY.MDD.P and are manually promoted from a chosen tested commit, with the patch slot incrementing when multiple stables ship on the same UTC date.

What verification is required before publishing a stable release?

Run pnpm -r typecheck, pnpm test:run, and pnpm build on the candidate SHA, confirm the canary published to npm, and smoke test with PAPERCLIPAI_VERSION=canary ./scripts/docker-onboard-smoke.sh. The stable workflow re-verifies the exact source ref before publishing.

What should I do if the canary smoke test fails?

Stop the stable release, fix the issue on master, wait for the next automatic canary publish, and rerun the smoke test. Do not promote a failing canary to stable.

How do I roll back a bad stable release on npm?

Run ./scripts/rollback-latest.sh <last-good-version> to repoint the latest dist-tag, then fix forward with a new stable release. Do not attempt to republish the same version.

Why does the release-content case creation return a 403 error?

A 403 response means Cases are disabled on the Paperclip instance. The operator must enable the experimental.enableCases flag before the release-content case tree can be created.