메뉴
Bundle release workflow — checkout, prepare, pr, diff-check, audit, publish, sync.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | 1k-bundle-release |
| description | Bundle release workflow — checkout, prepare, pr, diff-check, audit, publish, sync. |
| allowed-tools | Bash, Read, Write, Edit, Grep, Glob |
| disable-model-invocation | true |
Manages the bundle release workflow: developers branch from release/*, PRs target release/* directly, and after publishing, changes sync back to x via rebase.
OneKey ships periodic App Shell releases (tagged v{X.Y.Z} on the x branch). After each App Shell release, a release branch (release/v{X.Y.Z}) is created from the tag. Bundle release features are developed directly on this branch — PRs target release/*, not x. After bundle publishing, changes are synced back to x via rebase.
Release branch auto-detection: All subcommands use the shared detection logic below to determine the release branch. On a release/v* branch it's used directly; otherwise the latest release branch is discovered from the remote.
All subcommands MUST use this logic instead of reading .env.version directly. The reason: .env.version on x contains the next version (e.g., 6.2.0), while the release branch uses the current version (e.g., release/v6.1.0). Reading .env.version from x produces the wrong branch name.
current_branch=$(git branch --show-current)
if [[ "$current_branch" == release/v* ]]; then
# Already on a release branch — use it directly
RELEASE_BRANCH="$current_branch"
else
# Not on a release branch — find the latest one from remote
git fetch origin
RELEASE_BRANCH=$(git branch -r \
| grep 'origin/release/v' \
| grep -v mock \
| sed 's|origin/||' \
| sort -V \
| tail -1 \
| tr -d ' ')
fi
if [[ -z "$RELEASE_BRANCH" ]]; then
echo "No release branch found on origin."
exit 1
fi
After detection, confirm with the user:
"Detected release branch:
$RELEASE_BRANCH. Proceed? (y/n)"
If the user wants a different branch, let them specify it manually.
| No. | Subcommand | When to use | Guide |
|---|---|---|---|
1 | checkout | Start working on a bundle release feature | checkout.md |
2 | prepare | Set BUILD_NUMBER before triggering CI | prepare.md |
3 | pr | Create a PR from the current branch to release/* | pr.md |
4 | diff-check | Before publishing — quick changeset review | diff-check.md |
5 | audit | Before publishing — full security & supply-chain audit | audit.md |
6 | publish | Diff check passed — record release | publish.md |
7 | sync | After publishing — rebase to x | sync.md |
Parse the argument passed to this skill:
checkout [branch-name] or 1 [branch-name] → Read and follow checkout.mdprepare or 2 → Read and follow prepare.mdpr or 3 → Read and follow pr.mddiff-check or 4 → Read and follow diff-check.mdaudit or 5 → Read and follow audit.mdpublish or 6 → Read and follow publish.mdsync or 7 → Read and follow sync.md/1k-bundle-release checkout feat/my-fix ← Branch from release/* to start work
... develop ...
/1k-bundle-release prepare ← Set BUILD_NUMBER
/1k-bundle-release pr ← Create PR targeting release/*
... QA verifies, merge ...
/1k-bundle-release diff-check ← Quick changeset review
/1k-bundle-release audit ← Full security audit (optional, recommended)
/1k-bundle-release publish ← Record release in RELEASES.json (via PR)
/1k-bundle-release sync ← Rebase changes to x
These steps are designed to run in sequence, but each can also run independently.
| File | Location | Purpose |
|---|---|---|
| Version source | Auto-detected from current branch or remote release/v* branches | Determines release branch name |
| Release tracking | RELEASES.json (release branch root) | Each entry: seq, commit SHA, date, PR list, notes |
/1k-git-workflow — Branch naming, commit conventions/commit — Create commitsCreate or regenerate a patch-package patch in this monorepo. Use when you edit anything under node_modules/ and need a persisted .patch, or when `npx patch-package <pkg>` fails with "Couldn't find any versions for ... matches ^x@x". Keywords: patch-package, patch a package, regenerate patch, resolutions error.
App-side OneKey Trade/Swap/Market guide for Swap core, Swap Pro, Market speed-swap, K-line/chart, token selectors, cold-start frame-by-frame validation, quote/build/send flows, history/status, provider channels, PrivateSend-like channels, stock-trading channels, limit/order flows, fees, slippage, ETA, and cross-module funding handoffs.
Creates a Pull Request from current changes for OneKey app-monorepo. Use when user wants to create PR, submit changes, or merge feature branch. Handles branch creation, commit, push, and PR creation with conversation context extraction for code review AI.
AI-agent-driven UI verification for OneKey. Use to actually drive the running app and confirm a visual/interactive change works — Electron desktop via Chrome DevTools Protocol (CDP) on port 9222 with playwright-core, and React Native (iOS/Android) via callstack agent-device. Triggers on "verify the UI", "drive the app", "screenshot the change", "check it on desktop/simulator", "CDP 9222", "agent-device", "UI 验证", "跑一下看看", "截图确认".
App-side OneKey DeFi guide for Earn, Borrow, Staking, vaults, lending, protocol integrations, ABI-backed operations, native/provider-backed operations, pending transactions, history, route handoffs, risk display, and DeFi regression review.
Use only for explicit OneKey Perps/Hyperliquid (`views/Perp`, ServiceHyperLiquid, perpetuals, 永续/合约, Perps trading). Covers orderbook/L2/BBO, TWAP, scale/TIF/trigger/reduce-only, Perps TradingView/K-line, Perps Relay deposit, token selector, positions/account state/PnL/funding/margin/liquidation. Exclude generic Swap/Market/TradingView; Swap Relay quote/status/pending/requestId alone is not enough unless Perps deposit/Hyperliquid/`views/Perp`/`usePerpDeposit`/`fetchPerpDeposit*`/`perpsDepositOrderAtom` is explicit.