Menu
Pre-flight checks, commit hygiene, PR creation, and CI monitoring for shipping a branch. Use when the user says "ship", "ship it", "merge this", "raise a PR", or wants to go through the commit-and-PR workflow.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Take a set of local feature branches/worktrees all the way to merged PRs — discover unmerged work, fix commit-time hygiene, push, raise PRs, watch CI, auto-fix mechanical failures, merge on green, and cascade-rebase the rest. Use when the user says "shepherd PRs" or wants several branches driven to merge autonomously.
Read BEFORE invoking `playwright test` in any form, for any reason — running e2e, visual regression, room snapshots, or verifying a change 'via e2e'. Covers required project scoping (chromium-desktop, matching CI), the sandbox browser-build bridge, and the pnpm webServer failure. Also load on these failure signatures: every test failing at browserType.launch, 'Executable doesn't exist at /opt/pw-browsers/...', or 'Process from config.webServer was not able to start'.
Run the true-site-size GitHub Action locally via `act` inside the Claude Code web sandbox, to measure the game/editor cold-load journey byte cost without a CI round-trip. Use when asked to measure or verify build/wire size, or to check a byte-saving change, in the sandbox.
Fetch a campaign from the Supabase DB and save as local JSON. Use when the user asks to load, download, or fetch a campaign from the database.
Drive the Head over Heels remake's UI via the chrome-devtools MCP. Use this skill when the user asks for browser automation, capturing localStorage, dispatching game actions, or anything that involves driving the running game on localhost.
Run Docker — and tools that need it, like `act` (local GitHub Actions) — inside the Claude Code web sandbox, where image pulls and in-container networking collide with the egress proxy. Use when `docker pull` returns 403 on image layers, when a container can't reach the network, or when running `act`/CI-in-docker locally (e.g. the `act-true-site-size.sh` script).
| name | ship |
| description | Pre-flight checks, commit hygiene, PR creation, and CI monitoring for shipping a branch. Use when the user says "ship", "ship it", "merge this", "raise a PR", or wants to go through the commit-and-PR workflow. |
Walk through each phase in order. Ask the user before taking any destructive action.
Offer to run checks. If the user declines, skip to Phase 2.
eval "$(fnm env)" && fnm use && pnpm checkeval "$(fnm env)" && fnm use && pnpm build:game && pnpm playwright test --project=chromium-desktopReport results. If failures, offer to investigate before continuing.
Check whether the branch includes changes under src/editor/. If so, offer to QA the editor interactively via the chrome-devtools MCP.
Start the editor dev server (if not already running):
eval "$(fnm env)" && fnm use && pnpm dev:editor
Run in the background. Find the port with lsof -p <pid> -i -a | grep LISTEN.
Open in Chrome:
mcp__chrome-devtools__new_page({ url: "http://localhost:<port>/editor/" })
Access the Redux store at window._e2e_store:
const le = window._e2e_store.getState().levelEditor;
le.currentlyEditingRoomId;
le.campaignInProgress.rooms;
Reset to a clean campaign before testing:
window._e2e_store.dispatch({ type: "levelEditor/newCampaign" });
Exercise the changed features by dispatching actions directly (more reliable than clicking UI buttons, which suffer from stale uids after re-renders):
window._e2e_store.dispatch({ type: "levelEditor/<action>", payload: { ... } });
Verify state after each action by reading the store. Check room counts, door connections, item positions, toDoor cross-links, etc. Take screenshots for visual confirmation but treat the Redux state as the source of truth.
Persistence caveat: editor state persists to localStorage. If the state gets corrupted, clear it:
localStorage.removeItem("persist:hohol/levelEditor");
Then reload the page.
Report QA results to the user before proceeding.
Count commits ahead of main:
git rev-list --count origin/main..HEAD
Show them:
git log --oneline origin/main..HEAD
Confirm the commit message follows release-please conventions (check package.json or .release-please-manifest.json for the schema). If it looks good, proceed to Phase 3.
Offer to squash into a single commit. If the user confirms:
git reset --soft origin/main
git commit -m "<message>"
Draft the squashed commit message from the combined changes and ask the user to confirm it.
Explain the situation clearly: "There are N commits ahead of main, but some appear unrelated to this branch's purpose." List them and ask the user which commit(s) belong on this branch.
If the user confirms which to keep, offer to reset and cherry-pick:
git reset --hard origin/main
git cherry-pick <commit-sha>
This is destructive — get explicit confirmation before running git reset --hard.
If the unrelated commits need to be preserved elsewhere, suggest the user stash or branch them first.
Push the branch and create a PR:
git push -u origin HEAD
gh pr create -f
The -f flag uses the commit message as the PR title and body — this is the project convention.
Report the PR URL.
Offer to monitor the PR's CI checks in the background. If the user accepts, spawn a background agent that:
gh pr checks <pr-number> --watch or periodically runs gh pr checks <pr-number> with sleeps between polls.gh run view <run-id> --log-failed, summarises the failure, and offers possible fixes.Use ScheduleWakeup or a background Agent for the monitoring — don't block the main conversation.
Poll cadence: ~270s (stays within the prompt-cache TTL window).
Fallback timeout: 1200s if no signal.
Each poll:
gh pr checks <pr-number>
Parse the output for "fail", "pending", "pass" states. If all pass → notify success. If any fail → fetch logs and report.