code-ship

name	code-ship
description	Ship a ready branch. Syncs with dev, runs format and typecheck, runs tests, pushes, and opens a PR. For a ready branch, not for deciding what to build. Follows IronCode conventions: branch from dev, format with Prettier, typecheck before push.

/ship: Land the Branch

You are a release engineer. The branch is ready. Your job is to get it landed — no more ideation, no more refactoring. Execute the checklist and ship.

---

Step 1: Check branch state

git branch --show-current

If on dev: "You're on dev. Create a feature branch first." → STOP.

git status --porcelain

If there are uncommitted changes:

• Stage and commit them with a descriptive message
• If unsure about what to include, ask the user

---

Step 2: Sync with dev

git fetch origin dev --quiet
git rebase origin/dev

If rebase conflicts:

1. Show the conflicting files
2. Resolve conflicts (prefer the branch's changes unless clearly wrong)
3. git add <resolved-files> && git rebase --continue
4. If complex, ask the user

---

Step 3: Format

IronCode uses Prettier. Run the formatter before anything else:

./script/format.ts

If formatting changed files:

git add -A
git commit -m "chore: format"

---

Step 4: Typecheck

bun run typecheck

If type errors:

1. Fix them — these are real bugs
2. Commit the fixes: git commit -am "fix: resolve type errors"
3. If complex, show the errors and ask the user

---

Step 5: Run tests

Detect which packages were changed and run their tests:

# Get changed packages
git diff origin/dev --name-only | grep "^packages/" | cut -d'/' -f2 | sort -u

For each changed package:

bun --cwd packages/<package> test

If tests fail:

1. Diagnose — is it a real failure or a flaky test?
2. Fix real failures, commit the fix
3. If flaky, note it in the PR body and continue

---

Step 6: Pre-landing review (quick)

Do a fast scan of the diff for obvious issues:

git diff origin/dev --stat
git diff origin/dev

Check for:

• Debug console.log or console.debug left in code
• Commented-out code blocks
• TODO or FIXME comments that should be resolved
• Hardcoded test values (localhost URLs, fake emails, test tokens)
• Files that shouldn't be committed (.env, build artifacts, large binaries)

If anything found, fix and commit before pushing.

---

Step 7: Push and create PR

git push origin HEAD

Then create the PR against dev:

gh pr create \
  --base dev \
  --title "<type>: <concise description>" \
  --body "<auto-generated body>"

PR title convention: feat:, fix:, chore:, docs:, refactor:, perf:, test:

PR body template:

## What

One-paragraph description of the change.

## Why

What problem does this solve? Link to issue if applicable.

## Changes

- Bullet list of key changes
- Grouped by package if touching multiple

## Testing

- What was tested and how
- Test commands run and results

## Notes

- Any known limitations or follow-ups

If a PR already exists for this branch, update it instead:

gh pr edit --title "..." --body "..."
git push origin HEAD

---

Step 8: Confirm

Output the final status:

## Ship: [branch-name] → dev

✅ Synced with dev (no conflicts)
✅ Formatted (Prettier)
✅ Typecheck passed
✅ Tests passed (N packages)
✅ Pre-landing review clean
✅ Pushed to origin
✅ PR created: <url>

Branch is live. Ready for review.

---

Rules

1. Don't skip steps. Every step exists because something broke when it was skipped.
2. Format before typecheck. Prettier changes can affect line numbers in error messages.
3. Fix, don't ignore. Type errors and test failures are real. Fix them or explain why they're not.
4. Branch target is dev. Never ship directly to main unless explicitly told.
5. Commit messages matter. Use conventional commits: feat:, fix:, chore:.
6. No force push to shared branches. If the branch has been reviewed, don't rewrite history.
7. Momentum over perfection. The goal is to land the branch. If a non-blocking issue is found, note it as a follow-up.