Bump a CUBRID submodule to a commit

Dispatch submodule-bump-receiver.yml on CUBRID/cubrid so the parent repo pins a submodule to the commit you name. The Action opens a bump PR (or updates the open one). Normally the bump is automatic, one commit per PR; run this only when you need to catch up, pin a specific commit, or restart a stalled bump.

This triggers a real Action and touches a PR on the main repo. Never dispatch without showing the user what will happen and getting a yes.

Step 0: Check the state first (read-only)

bash ${CLAUDE_SKILL_DIR}/assets/bump_submodule.sh --status             # all three, at a glance
bash ${CLAUDE_SKILL_DIR}/assets/bump_submodule.sh <submodule> --status # that one's pending commits

Read-only, so run it without asking first. One call reports, for all three submodules, the pinned SHA, the submodule head, how many commits are pending, and the open bump PR.

When the open PR already pins the head there is nothing to dispatch: merging that PR is the whole job. The script says just merge it in that case, so guide the user to merge rather than suggesting a run.

The per-submodule view lists only the commits added after the pinned one, oldest first and numbered (up to 20; beyond that it states how many remain). That number is exactly "how far to bump", so pick the SHA here when the user wants to stop at a specific commit.

Step 1: Resolve the target

cubrid-manager-server is the repository name; cubridmanager is the submodule path the workflow expects. The helper accepts either.

The SHA can be a full 40-char SHA, a short SHA (it is expanded), or latest for that submodule's develop head. Anything else is rejected.

Step 2: Validate (dry run, dispatches nothing)

bash ${CLAUDE_SKILL_DIR}/assets/bump_submodule.sh <submodule> <sha|latest>

It prints the currently pinned SHA, the target, the direction of the move, and a compare link, then shows the exact gh command without running it. It refuses, and dispatches nothing, when:

Step 3: Show it and get confirmation

Show the user the summary from Step 2 (pinned -> target, how many commits, the compare link) and ask whether to dispatch. Do not run it on your own initiative.

Everything up to the chosen SHA comes in: you cannot cherry-pick a middle commit. Naming commit 3 brings 1 and 2 with it.

Step 4: Dispatch

bash ${CLAUDE_SKILL_DIR}/assets/bump_submodule.sh <submodule> <sha|latest> --run

Then report the run:

gh run list --repo CUBRID/cubrid --workflow submodule-bump-receiver.yml --limit 3

--reanchor (normally never)

The parent records one anchor commit to mark how far it has bumped. If a force-push rewrites the submodule's history, that anchor disappears from develop and the workflow stops. --reanchor is only for that: name the corresponding commit in the new history and it re-attaches the anchor there.

On healthy history it does nothing, and it cannot move the pin backward. Add it only when the user explicitly asks: never on your own judgement.

Guardrails

• This skill runs only submodule-bump-receiver.yml on CUBRID/cubrid. Never point gh workflow run at another workflow or repo.
• Anything outside the three allowed submodules is refused without running gh at all.
• Never jump to --run without the Step 2 validation.
• A failure leaves the parent repo untouched: bad input is refused before anything is pinned.