Create PR

/create-pr — Open a PR and babysit it to green

Create a pull request for the working changes, then stay with it: watch CI and the Greptile review at the same time, fix whatever lands first, and keep looping until every check is green and the review is clean (or the user tells you to stop). Greptile's feedback almost always arrives before CI finishes — address it then, rather than sitting on it until the rollup completes.

Repo rules that this skill must honor (from CLAUDE.md):

• PRs target dev, never main.
• Commit subjects are imperative, ≤50 chars. Never add Co-Authored-By trailers or mention coding agents.
• Update CHANGELOG.md before opening the PR for any user-facing feature, fix, or breaking change (skip for pure internal refactors). New changes go under ## [Unreleased], never under an already-released version.

1. Pre-flight — get the change into shape

1. git status and git diff --stat to see what's staged/unstaged. If there are no changes at all, stop and tell the user.
2. Run the quality gates for what changed (don't run the whole world if only one side changed):
   • scripts/ci/check: the fast checks CI runs, by the same script CI calls (ruff, ruff format, ty, frozen migrations and one Alembic head, biome, tsc, and generated-types / env-contract.json drift), for what the branch changed against origin/dev. No database, no tests; seconds. When codegen fails, read why before committing anything:
     • "it differs from what is committed": it has regenerated the files. Review the diff and commit it.
     • "uncommitted changes, which regenerating would overwrite": it stopped before generating. Commit or discard those changes and run it again.
     • anything else (a missing .venv or node_modules, an export error): nothing was regenerated. Fix that and run it again.
   • Tests for what changed: cd backend && ./scripts/test-changed.sh and cd frontend && ./scripts/test-changed.sh. Fix anything that fails before opening the PR — a red gate locally will be red in CI, and a CI round-trip on this repo costs up to ~26 minutes. Never push a speculative fix hoping CI will validate it; reproduce it locally first.
3. If the change is user-facing, add a concise CHANGELOG.md entry under ## [Unreleased] in the right subsection (Added / Changed / Fixed / Security).

2. Branch, commit, push

1. Determine the current branch (git branch --show-current). If it is dev or main, create a fresh feature branch off it: git checkout -b <type>/<short-kebab-summary> (e.g. fix/…, feat/…). If already on a feature branch, keep using it.
2. Stage the intended files explicitly and commit. Imperative subject ≤50 chars; add a body explaining the why. No Co-Authored-By, no agent mentions. A pre-commit hook (lint-staged/biome) may run — let it.
3. git push -u origin <branch>. The husky pre-push hook runs scripts/ci/check again for what the branch changed; if it fails, fix and push again rather than skipping it with --no-verify.

3. Open the PR

Create it against dev with a structured body:

gh pr create --base dev --title "<imperative title>" --body "$(cat <<'EOF'
## Problem
<what was wrong / what this enables>

## Changes
- <bullet per notable change, link files as [name](path)>

## Testing
- <exact commands you ran and their result>

Fixes #<issue>   # only if it closes an issue
EOF
)"

Capture the PR number from the returned URL.

4. Watch CI and Greptile together

Greptile usually posts its first review while CI is still running, and CI failures usually surface one job at a time. Do not wait for the whole rollup to finish before reading review feedback — watch both signals in one loop and act on whichever lands first.

Snapshot what you have already seen, then wait for the next event:

REPO=$(gh repo view --json nameWithOwner -q .nameWithOwner)
PR=$(gh pr view --json number -q .number)

# Baseline: the newest Greptile review id we've already read (0 if none yet).
seen_review() {
  gh api "repos/$REPO/pulls/$PR/reviews" \
    --jq '[.[] | select(.user.login|test("greptile";"i")) | .id] | max // 0'
}
SEEN=$(seen_review)
START=$(date +%s)

# Wait for: a new Greptile review, a failed check, or everything green.
while :; do
  FAILED=$(gh pr view "$PR" --json statusCheckRollup \
    -q '[.statusCheckRollup[] | select(.conclusion=="FAILURE" or .conclusion=="TIMED_OUT") | .name] | join(", ")')
  PENDING=$(gh pr view "$PR" --json statusCheckRollup \
    -q '[.statusCheckRollup[] | select(.status!="COMPLETED")] | length')
  NOW=$(seen_review)
  if [ "$NOW" != "$SEEN" ]; then echo "EVENT=greptile review=$NOW"; break; fi
  if [ -n "$FAILED" ];       then echo "EVENT=ci-failure jobs=$FAILED"; break; fi
  if [ "$PENDING" -eq 0 ];   then echo "EVENT=ci-green"; break; fi
  echo "waiting: $PENDING check(s) pending, $(( $(date +%s) - START ))s elapsed"
  sleep 30
done

Run this in the background (run_in_background: true). A full backend run takes up to ~26 minutes, and the Bash tool caps a foreground call at 600000ms (10 min) — a blocking wait cannot cover one cycle, and blocking the session for 26 minutes would be wrong even if it could. Background it, do the Greptile work while it runs, and read its output when it breaks.

Each time it breaks, handle the event (§5 or §6) and then re-enter this loop with SEEN updated to the review you just read. The loop is only finished when EVENT=ci-green and the Greptile bar in §5 is met.

Batching pushes. A push cancels the in-flight run and restarts it from zero, so never push once per finding — collect a whole Greptile round (plus any CI failure already visible) into one commit and push once.

Given the timings, the usual call is easy: Greptile posts within a minute or two, when the backend job has barely started, so push the batch as soon as it's ready — you're discarding two minutes of a run that was testing the pre-fix commit anyway, and the fixed code's results arrive ~26 minutes from the push either way. Waiting for the current run to finish first just adds its remaining time to that.

Hold the push only when the run is nearly done and its result would change what you commit — you're minutes from learning about failures you'd want to fold into the same batch.