release

The full skill.

Original instructions from the publisher’s SKILL.md

# Release

Prepare a complete, consistent `timepicker-ui` release in one flow. This skill is a thin
orchestrator: the real work is done by the **`build-release`** subagent. The skill exists to
decide the version with you and to hold the **approval gate** the subagent can't run itself.

The version source of truth is the **root `package.json`** (`timepicker-ui`) — the ONLY `version`
field a release ever changes. `app/package.json` (build workspace) and `docs-app/package.json`
(docs site) are each a *separate application's own version*; a release NEVER touches their
`version` field. What a release does in `docs-app/` is update the **content that references the
library version** — the changelog page, what's-new, and `npm i timepicker-ui@x.y.z` install
snippets — not the docs site's own app version.

**The changelog is about the library, not the docs site.** `CHANGELOG.md` and the docs-app
changelog page record changes to the published `timepicker-ui` package only. Changes to
`docs-app/` itself (SEO, page content, demo fixes, favicons, docs-site bugs) are NEVER logged
and never bump the version — the docs site is a separate app the library does not track. The
docs-app changelog page just *presents* the library changelog. If a release touched only
`docs-app/`, there is no library release to cut — say so instead of inventing entries.

## Arguments (optional)
- A version or bump type: `/release patch`, `/release minor`, `/release major`, or an explicit
  number `/release 4.4.0`. If omitted, the skill proposes a bump from the changes since the last
  release and asks you to confirm.
- `--apply-all` skips the per-area approval prompt and applies the whole audited plan (still
  reports + sanity-builds at the end). Use only for an explicitly unattended run.

## Workflow

### Phase 1 — Decide the version (gate)
1. Read the current version from root `package.json`. Skim what changed since the last release
   (read-only `git log` / `git diff` against the last release tag/commit, plus the working tree)
   to judge magnitude. The branch name (e.g. `feature/4.4.0`) is a strong hint at intent.
2. Propose a SemVer bump with a one-line rationale:
   - `patch` — bug fixes / internal only, no public API change
   - `minor` — new backwards-compatible options/plugins/themes/methods
   - `major` — breaking change to public API, option groups, `getValue()` shape, exports, or the
     `tp-ui-` CSS class contract (requires migration notes)
3. **Use AskUserQuestion** to confirm the exact new version before anything else. If the user
   passed a version/bump as an argument, still confirm it. The number is a promise to consumers.

### Phase 2 — Audit (read-only)
Dispatch the `build-release` subagent (Task tool, `subagent_type: build-release`) in **audit mode**
with the confirmed new version. Ask it to return a file-level plan, making NO edits:
1. Every place that must be bumped (root `package.json`; README version-pinned Socket badge +
   any Features/Options/Themes/Plugins/API/Upgrading sections affected by this release).
2. The **historical** version references it will deliberately leave untouched (prior CHANGELOG
   entries, docs-app `<Section>` blocks, "Removed in v4.0.0", migration guides) — listed so you
   can see nothing historical gets rewritten.
3. A drafted **CHANGELOG.md** entry (`## [x.y.z] - YYYY-MM-DD`, grouped Added/Changed/Fixed/…,
   user-facing copy) derived from the actual diff/commits — not invented.
4. The matching docs-app updates: a new `<Section>` for `app/(site)/docs/changelog/page.tsx`, the
   what's-new highlights, and any install/banner version strings.

### Phase 3 — Present & approve (gate)
Relay the plan concisely: proposed version, the drafted changelog, the bump list, and the
"leave historical" list. **Use AskUserQuestion** to approve as-is, edit the changelog copy, or
narrow scope (e.g. skip docs-app this round). Capture the approved version + final changelog
text. Do not skip this gate unless `--apply-all` was passed.

### Phase 4 — Apply
Dispatch `build-release` again in **apply mode** with the approved version and final changelog.
It edits root `package.json`, README (badge + affected sections), `CHANGELOG.md`, and the
docs-app changelog/what's-new/version strings — bumping only current-version references and
leaving historical ones intact. It matches docs-app's own conventions (not the library's CRLF
rules) for docs-app files.

### Phase 5 — Sanity build & report
- Run a build to confirm nothing broke: `cd app && npm run build:prod` (or `build:tsup` +
  `build:rollup`). Report pass/fail with the real output — never claim green without running it.
  If the user prefers to run it themselves, offer rather than assume.
- Summarize: new version, every file changed (grouped: package.json / README / CHANGELOG /
  docs-app), and confirmation that `exports` / `sideEffects` / entry points / zero-dependency /
  tree-shaking are intact.
- **Propose the release commands for the user to run** — git is theirs:
  a commit message, the tag (`vX.Y.Z`), and the publish step (`npm publish`). Do NOT run
  `git add/commit/tag/push` or `npm publish` yourself.

## Guardrails
- One source of truth for the version (root `package.json`). NEVER touch the `version` field of
  `app/package.json` or `docs-app/package.json` — those are separate apps, not the library. In
  `docs-app/` a release only edits content that *references* the library version (changelog /
  what's-new / install snippets), never the docs site's own `version`.
- Never rewrite historical version references or past changelog entries.
- Keep `.claude/` and library files CRLF; docs-app files keep docs-app's own style.
- This skill prepares a release; it does not execute git or npm publish.