release

# Release Skill Use this skill to generate release-ready changeset entries in the repository style. ## Scope - Review current branch changes. - Propose release impact (major/minor/patch) from code diffs. - Draft concise Changesets-compatible summaries. - Preview and ask for explicit user confirmation. - Create or update `.changeset/*.md` only after confirmation. ## Required style Follow `docs/changeset-style.md` strictly: 1. Start with one plain summary sentence without a list marker. 2. Add up to five optional follow-up bullets (`- ...`); keep every line concise and user-facing. 3. No headings, code blocks, root-cause sections, or file lists. 4. Keep implementation detail in PR discussion/docs, not release notes. Target package frontmatter: ```yaml --- "react-native-reanimated-carousel": patch --- ``` Replace `patch` with `minor` or `major` when justified. ## Workflow 1. Gather branch context. - Run `git status --short`. - Run `git diff --name-status origin/main...HEAD`. - If `origin/main` is unavailable, fallback to `git diff --name-status main...HEAD`. - Review commit titles with `git log --oneline --no-merges origin/main..HEAD` (or fallback). 2. Detect existing pending changesets. - List `.changeset/*.md` excluding `README.md`, `config.json`, `pre.json`. - If a suitable pending changeset exists, prefer updating it instead of creating duplicates. 3. Infer bump recommendation from diff. - Build signals from changed files and commit intent: - Breaking/API risk signals: removed or renamed public props/exports/types, stricter peer dependency floor, explicit migration-required notes. - Feature signals: new props/options/apis/behaviors that are backward compatible. - Fix signals: bug fixes, tests, docs, refactors without new public API. - Select a primary recommendation: - `major` when breaking/API risk signals are present. - `minor` when feature signals dominate and no breaking signal exists. - `patch` when only fix signals exist. - Always prepare one alternative recommendation when uncertainty exists. 4. Produce a preview for user confirmation. - Show `Proposed bump` with confidence (`high`/`medium`/`low`). - Show `Why` with 2-4 concise evidence bullets from actual diff/commits. - Show `Alternative bump options` with one-line tradeoff for each. - Show exact markdown content to be written. - Ask: `Reply with confirm to write this changeset, or tell me what to edit.` 5. Only after explicit confirmation, write file changes. - Create a kebab-case file name, e.g. `.changeset/release-<topic>.md`. - Or update the agreed existing changeset file. 6. Validate. - Run `node scripts/check-changeset-style.mjs`. - If validation fails, fix and re-run until pass. - Optionally run `yarn changeset:check` if dependencies are installed. 7. Report result. - Return the file path, bump type, final bullets, and validation result. ## Decision rules for bump type - `patch`: bug fixes, behavior corrections, internal improvements with backward compatibility. - `minor`: backward-compatible features, new props/options/behavior. - `major`: breaking API/behavior/dependency requirements requiring migration. If uncertain between two bump levels, surface both options in preview and ask user to choose before writing. ## Output contract When previewing, always include: 1. `Proposed bump:` 2. `Confidence:` 3. `Why:` 4. `Alternative bump options:` 5. `Draft changeset:` fenced markdown block using a plain first summary line 6. `Confirmation prompt` Never write or modify `.changeset/*.md` before explicit `confirm`.