suwappubot: Command for Claude Code

Ship Skill

Runs the full ship loop. Two rules that outrank everything below:

1. Do NOT merge while CI is red.
2. Shipping does not end at "merged." It ends when the deployed system is verified running the code you merged, and its logs are clean. Steps 6-8 are not optional epilogue — they are where every failure this repo has actually hit gets caught.

Optional arg: a PR title. If omitted, infer a concise conventional-commit title from the diff.

Why this skill is shaped like this

Every cheap gate proves something NARROWER than what we want to conclude:

Gate	Reads as	Actually proves
Railway deploy SUCCESS	the code works	a container built and started
A green deploy with a loose install	deps are correct	drift is undetectable here
CI green on your branch	main is green	nothing about main
Service status SUCCESS	running current code	some build, of some commit, sometime
/health 200	the bot booted	that host answered
No ImportError in logs	nothing is wrong	no ImportError

So verify the specific thing, per service, and then read the logs. Never generalise one green signal into a claim about a different component.

Step 0 — Pre-flight (CLAUDE.md mandatory checklist)

REPO=$(git rev-parse --show-toplevel); cd "$REPO"
git rev-parse --abbrev-ref HEAD
git rev-parse --git-common-dir              # a worktree? then NEVER rebase
ls .git/*.lock 2>/dev/null || echo "no locks"
git stash list | head
git status --short
git status --short | grep -iE "node_modules|\.next/|dist/" && echo "ARTIFACTS — gitignore first, stop" || true
git fetch origin main -q && git rev-list --left-right --count origin/main...HEAD

If on main, branch first — never commit straight to main.

Step 1 — Format, parse, and LOCKFILE check (CI gates on all three)

PYF=$(git status --short | awk '{print $2}' | grep '\.py$')
[ -n "$PYF" ] && python3 -c "import ast; [ast.parse(open(f).read()) for f in '''$PYF'''.split()]; print('parse ok')"
[ -n "$PYF" ] && black --line-length=100 $PYF

If you changed ANY package.json, you must regenerate its lockfile — CI runs bun install --frozen-lockfile in showcase/, terminal/, webapp/, api-ts/ and mobile. A missing lockfile update fails CI even when every deploy is green. Use the bun version CI pins (see .github/workflows/test.yml) — a lockfile written by a different bun can fail the frozen check on its own:

BUN_PIN=$(grep -m1 'bun-version:' .github/workflows/test.yml | awk '{print $2}')
npm i --no-save bun@"$BUN_PIN" >/dev/null 2>&1
for d in showcase terminal webapp api-ts; do
  [ -f "$d/bun.lock" ] || continue
  (cd "$d" && ../node_modules/.bin/bun install --frozen-lockfile >/dev/null 2>&1) \
    && echo "$d lockfile OK" || echo "$d LOCKFILE DRIFT — run: (cd $d && bun install) and commit"
done