メニュー
Bump version of both SDK packages (headless + UI), update both CHANGELOGs, and commit. Use when the user wants to release a new version, bump the SDK, or cut a release.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Installs and wires the `@rocapine/react-native-onboarding-ui` UI SDK on top of the headless SDK. Use when the user wants prebuilt onboarding screens, asks "add the UI SDK", "render the onboarding step", or "use OnboardingPage".
Builds the inner UIElement tree of a ComposableScreen step. Inspects the target app's design system before composing. Use when authoring a ComposableScreen, asks "compose a screen", "build the UIElement tree", "design the layout", or needs branching/variables in a single screen.
Authors a new Rocapine Onboarding Studio step using exclusively the ComposableScreen step type. Inspects the target app for design system, fonts, tokens, and copy voice before generating. Use when the user wants to add an onboarding screen, draft a step, or asks "give me JSON for an onboarding step".
Customizes how Rocapine ComposableScreen UIElements render in the host app — via element props (primary path) and host-wired `custom` button actions (advanced path). Use when the user wants a different look for buttons / radio cards / inputs, wants the onboarding to share components with the rest of the app, or asks "customize the button", "use my own component for X", "wire a custom action".
Finds an existing onboarding flow already implemented in the target app's source code (screens/modules named onboarding, welcome, intro, getting-started) and converts each screen into a Rocapine ComposableScreen step JSON. Preserves the app's exact design — colors, fonts, radii, copy, navigation order — pulled from the source code. Use when the user says "export my existing onboarding", "convert my onboarding screens to Rocapine", "I already have onboarding in the app — generate the JSON", "migrate the onboarding to the SDK", or "recreate my onboarding as steps".
Validates a Rocapine ComposableScreen step JSON against the headless SDK Zod schemas. Use when the user pastes step JSON and asks "is this valid", "check this onboarding step", "validate this payload", or after creating step JSON.
| name | bump-version |
| description | Bump version of both SDK packages (headless + UI), update both CHANGELOGs, and commit. Use when the user wants to release a new version, bump the SDK, or cut a release. |
| user-invocable | true |
| argument-hint | [patch|minor|major] |
Bump both @rocapine/react-native-onboarding and @rocapine/react-native-onboarding-ui to a new version, write changelog entries for both, and create a commit.
Both packages always share the same version number.
Run:
git diff main...HEAD -- packages/
Also run:
git log main...HEAD --oneline
Read the diff carefully. Classify each change:
| Signal | Bump |
|---|---|
| Breaking API change, removed export, type narrowing that breaks callers | MAJOR |
| New feature, new UIElement, new prop, new hook, new export | MINOR |
| Bug fix, style tweak, internal refactor, doc update, example update only | PATCH |
Use the highest applicable level across all changes.
Show a compact summary:
Changes on this branch:
• <bullet per logical change>
Recommendation: MINOR — new feature added (no breaking changes)
Bump type? [PATCH / MINOR / MAJOR]
If the user passed an argument (/bump-version patch), skip asking and use that directly.
Wait for confirmation before proceeding.
Read current version from packages/onboarding/package.json (field "version").
Apply the bump:
x.y.Z+1x.Y+1.0X+1.0.0Call this NEW_VERSION.
Edit all three files — only the "version" field:
packages/onboarding/package.jsonpackages/onboarding-ui/package.jsonclaude-plugin/.claude-plugin/plugin.jsonSet "version": "<NEW_VERSION>" in each. The Claude Code plugin always tracks the SDK version it was tested against.
Read the diff again (already done in Step 1). Write a changelog entry for each package separately — the headless SDK entry describes schema/type/hook changes; the UI entry describes renderer/component/theme changes. Be specific and useful; follow the existing entry style in each file.
Format to prepend (insert after the --- separator line at the top, before the previous ## [x.y.z] entry):
## [NEW_VERSION] - YYYY-MM-DD
### Added
- **X** — description.
### Changed
- **Y** — description.
### Fixed
- **Z** — description.
---
Only include sections that apply. Today's date: read from the environment or use the date in the conversation context.
Files to update:
packages/onboarding/CHANGELOG.mdpackages/onboarding-ui/CHANGELOG.mdStage only the four files:
git add packages/onboarding/package.json packages/onboarding-ui/package.json packages/onboarding/CHANGELOG.md packages/onboarding-ui/CHANGELOG.md
Commit message format (gitmoji conventional):
📦 chore(release): bump to <NEW_VERSION>, update changelogs and docs
Show the user the proposed commit message before running — confirm then commit.
Do not push. Do not run npm publish. The user handles publishing separately.
Print:
Bumped: x.y.z → NEW_VERSION (BUMP_TYPE)
Commit: <sha or "done">
Next: npm run publish:all (when ready to publish)