releaselisted

# release Cut a new npm release of `@robr0/design-system` — bump, dry-run, publish, tag. ## When invoked Use this skill when asked to cut a release, publish a new version, or ship the package to npm — phrases like "cut a release", "publish the next version", "ship the package". **This is the one workflow in this repo where a mistake is permanent.** npm never lets a version number be reused, even after unpublishing, so a botched publish burns that version forever. Read the guardrails before starting. ## Instructions ### 1. Decide the version Read `PACKAGE_VERSION` in `scripts/package-manifest.mjs` — that constant is the *authoritative* version; two other files mirror it (see step 3) and `validate-package-exports.mjs` fails the build when they disagree (the root package.json version is a hand-maintained mirror; `dist/package.json` is generated from the manifest). Then pick the next version from what actually changed since the last release: - **patch** — bug fixes, internal refactors, docs - **minor** — new components, new exports, new tokens (additive) - **major** — a renamed/removed prop, export, or token; anything a consumer must edit code for Check what shipped since the last tag to justify the choice, and confirm it with Rob before bumping: ```bash git log $(git describe --tags --abbrev=0)..HEAD --oneline ``` Be deliberate about breaking changes: components are exported both from the barrel and from `./components/*` deep paths, so a renamed component folder break