release

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

Updated Mar 26, 2026
One-click install
npx skills add https://github.com/nabitllc/todero --skill release-nabitllc
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: release
Source: https://github.com/nabitllc/todero/tree/main/.agents/skills/release
Command: npx skills add https://github.com/nabitllc/todero --skill release-nabitllc

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Shipping a Todero release involves many coordinated steps—changelog drafting, canary validation, smoke testing, stable promotion, GitHub Release creation, and announcement follow-up—and missing any one of them can ship a broken or undocumented release. 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 case tree (parent release case plus blog_post and tweet_storm children) via the Todero 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, promote it to stable on npm, create the GitHub Release, and file the announcement follow-up tasks. ## Quick Start Ask the agent to ship the stable Todero 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 canary release to stable in Todero?

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 manual workflow_dispatch with source_ref, stable_date, and dry_run inputs. Run a dry-run first, then the live publish.

How does Todero release versioning work?

Todero uses a commit-driven model where every push to master publishes a canary as YYYY.MDD.P-canary.N, and stable releases use YYYY.MDD.P. The patch slot increments when multiple stables ship on the same UTC date, and only stables get changelog files, git tags, and GitHub Releases.

What preconditions are required before running a Todero release?

The working tree must be clean, a candidate commit must exist since the last stable tag, the candidate must pass the verification gate, and npm publish rights must be available. The release-changelog skill must also exist, and any CI-owned pnpm-lock.yaml refresh must already be merged.

What should I do if the canary smoke test fails?

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

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

Run ./scripts/rollback-latest.sh with the last known good version to repoint the latest dist-tag. Then fix the underlying issue and ship a new stable release rather than republishing the same version.