| name | ck-ship-pr |
| description | Publish CK superproject and submodule work like ck-ship-dev, but submodules go out as feature-branch PRs for the maintainer to merge instead of direct dev pushes. Use when the user asks to ship via PRs, or when the session's maintainer has a standing PR-first preference. |
Ship via PRs — the review-first variant of ck-ship-dev
Follow ck-ship-dev steps 0–4 and 7 EXACTLY (pre-flight,
commits, fetch + divergence table, rebase + backup branch, regate, final report).
This skill replaces ONLY the two publish steps — everything else stays single-sourced
in ck-ship-dev so the procedures never drift apart.
5-PR. Publish the submodules as PRs
Only after the gate is green and each repo is N ahead / 0 behind:
git -C <submodule> push origin <feature-branch>
gh pr create --base dev --head <feature-branch> ...
- Long-lived legacy branches (e.g. CkFoundation
feature/5.5-temporary) are their
own canonical target — push those direct, exactly as ck-ship-dev does.
- ck-ship-dev's withhold rule applies unchanged: don't publish a submodule a sibling
session is actively mid-work in.
6-PR. Gitlink bumps wait for the merge
STOP until the maintainer merges each submodule PR: a superproject gitlink must
point at a SHA reachable from the submodule's origin/dev, and a squash-merge
REWRITES your SHAs. After the merge: fetch, re-point local dev at origin/dev,
re-verify containment (git -C <sub> merge-base --is-ancestor <pointed-SHA> origin/dev), then bump exactly as ck-ship-dev step 6 prescribes.
The superproject publish follows the same default: feature-branch PR unless the user
explicitly asks for a direct dev push (or the superproject's flow is already
PR-gated, e.g. BusterBlock feature/ branches → CI).
