| name | release |
| description | Cut a sim-use release end-to-end. Use when the user runs `/release` or asks to "ship a release", "publish a version", "cut a release", or "release to homebrew". Drives scripts/local-release.sh; never reimplement its build/sign/tarball logic. |
This skill ships a new version of sim-use. The human types /release and you handle everything: version, CHANGELOG, one confirmation, then drive every command through to the homebrew-tap commit.
Run from the sim-use repo root (git rev-parse --show-toplevel).
The build/sign/tarball/formula logic lives in scripts/local-release.sh. Do not duplicate it. Your job is orchestration: state checks, version arithmetic, CHANGELOG rendering, user confirmation, git/tap operations, error recovery.
Step 1: Pre-flight
Run these checks. Abort with a clear error if any fails.
- Current branch is
main.
- Working tree is clean (
git status --porcelain returns nothing).
- Local main is in sync with origin (
git fetch origin main then compare HEADs). If local is ahead, ask to push first; if behind, abort.
gh auth status succeeds (github.com).build_products/Frameworks/ exists. If missing, run scripts/build.sh dev to build them.- The homebrew-tap clone exists at
../lycorp-jp-homebrew-tap. If missing:
git clone git@github.com:lycorp-jp/homebrew-tap.git ../lycorp-jp-homebrew-tap
If it exists, verify it's clean and pull latest.
- Android bridge toolchain:
scripts/build-bridge.sh --check succeeds.
7.5. E2E confidence suites are green (see docs/ai/xxxx-e2e-confidence-suite/):
make e2e
(make e2e-ios / make e2e-android run one platform each.) A full green
iOS pass alone is ~15 min, so budget ~20+ min. It prints a full pass/fail
map and keeps going past failures. Any red suite blocks the release unless
the user explicitly waives it at Step 3.
Optional but recommended when skill prose changed this release (real
claude -p cost): make eval ARGS="-y -t quick" — the /run-evals
skill covers environment prep (Device Hub closed, fixtures installed)
and pinning which sim-use binary is under test.
- Signing + notarization readiness:
security find-identity -v -p codesigning | grep -F "NAVER Japan K.K. (GFPYJQXRSN)"
xcrun notarytool history --keychain-profile sim-use-notary >/dev/null 2>&1
If either fails, surface the gap at Step 3 — don't silently switch to ad-hoc.
Step 2: Determine version and draft CHANGELOG
- Find latest tag:
git tag --list 'v*' --sort=-v:refname | head -1.
- Read commits since last tag:
git log <last-tag>..HEAD --pretty=format:'%h %s'.
- Auto-bump based on conventional commits:
feat!: / BREAKING CHANGE → majorfeat: → minor- Only
fix: / chore: / docs: → patch
- Draft CHANGELOG entry from commits. Group by:
### Added / ### Changed / ### Fixed / ### Removed. Omit pure refactor/chore/test commits. Match existing CHANGELOG style.
- Backlink every entry to its pull request(s) and thank external contributors. This is part of how the project builds its contributor community — never skip it.
- Append the PR reference(s) at the end of each entry:
(#NN). When the work arrived through an original PR plus an internal hardening/follow-up PR, reference both: (#NN, #MM).
- When any referenced PR was authored by an external contributor (not the maintainer), turn the reference into thanks:
(#NN — thanks @user!). Entries whose PRs involve only the maintainer keep the bare number.
- Mapping technique:
git blame the [Unreleased] lines, then git log --merges --ancestry-path <sha>..main — the earliest merge is the introducing PR. Watch for externally-authored PRs that GitHub marked merged because their commits landed via an internal branch (no own merge commit); credit the original PR alongside the one that carried it.
- Cross-check the reverse direction: every merged PR with user-facing impact should have an entry. A contributor's fix missing from the CHANGELOG means missing credit — add the entry.
- Also prepare the
bridge/app/build.gradle.kts version bump: versionName → new version, versionCode += 1.
If the user specified a version (e.g. /release 0.10.0), use that verbatim.
Step 3: Confirm with the user (single gate)
Show:
- Previous tag → next version
- Commit list (one line each)
- Proposed CHANGELOG diff (entries must carry their PR backlinks and contributor thanks from Step 2.5)
- Release shape: notarized (default) or ad-hoc fallback (if Step 1.8 failed)
Ask: "Ship vX.Y.Z with this CHANGELOG?"
Accept: yes / no / version override / CHANGELOG edit / "use ad-hoc fallback".
Step 4: Apply changes and commit
- Edit
CHANGELOG.md: leave ## [Unreleased] empty, insert ## [X.Y.Z] - YYYY-MM-DD below it.
- Edit
bridge/app/build.gradle.kts: bump versionName and versionCode.
- Commit:
git add CHANGELOG.md bridge/app/build.gradle.kts
git commit -m "chore(release): vX.Y.Z"
git push origin main
Step 5: Tag
git tag vX.Y.Z
git push origin vX.Y.Z
Step 6: Run the release pipeline
Notarized (default):
scripts/local-release.sh \
--version X.Y.Z \
--codesign-identity "Developer ID Application: NAVER Japan K.K. (GFPYJQXRSN)" \
--notarize \
--notary-profile sim-use-notary \
--gh-release \
--tap-dir ../lycorp-jp-homebrew-tap
Ad-hoc fallback (only if user explicitly opted in):
scripts/local-release.sh \
--version X.Y.Z \
--gh-release \
--tap-dir ../lycorp-jp-homebrew-tap
If the script fails midway:
- Bridge build failed →
scripts/build-bridge.sh --check, see AGENTS.md Android pitfalls
- Notarization rejected → check
dist/notary-vX.Y.Z.log
- GitHub release create failed → re-run (script falls back to
gh release upload --clobber)
- Smoke test failed → surface exact error, don't paper over
Step 7: Commit and push the tap
cd ../lycorp-jp-homebrew-tap
git add Formula/sim-use.rb
git commit -m "sim-use vX.Y.Z"
git push origin main
cd -
Step 8: Report
Show:
Dry-run mode
If the user passes dry-run or "preview", run Steps 1-3 only. Show what would happen, then stop.
Things to NOT do
- Don't modify build scripts as part of a release run — build behavior changes go through their own commit.
- Don't auto-resolve git conflicts on CHANGELOG.md.
- Don't force-push tags.
- Don't
brew install the fresh formula on the developer machine.
