land-batch

name	land-batch
description	Triage, review, and sequentially merge multiple open PRs. Handles CI monitoring, conflict resolution between PRs, Codex-style review, and post-merge deploy verification. Use when asked to "land all PRs", "merge open PRs", or "triage and ship".
allowed-tools	Bash, Read, Grep, Glob, Write, Edit, Agent, AskUserQuestion

Land Batch

Triage open PRs -> prioritize -> review each -> merge sequentially -> verify deploys.

This skill takes a set of open PRs from "open" to "merged and verified." It handles the full batch landing sequence: triage/prioritization, per-PR review, conflict resolution between sequentially-merged PRs, and post-merge deploy tracking.

Input

Accepts one of:

• No argument — all open PRs on the current repo
• PR numbers (e.g. 3040 3051 2965) — specific PRs to land
• Label/filter (e.g. --label ready-to-merge) — filtered set

Step 0: Discover + Triage

0a: List open PRs

gh pr list --state open --json number,title,headRefName,createdAt,labels,statusCheckRollup,additions,deletions,files

0b: Classify each PR

For each PR, determine:

• Scope: files changed, apps affected (function-v2, web-front, web-client, etc.)
• Risk: LOW (config/docs/deletion), MEDIUM (feature, new routes), HIGH (infra, DB, auth)
• CI status: all green, partial fail, not run
• Merge readiness: clean, has conflicts, needs rebase
• Dependencies: does PR X need to land before PR Y?

0c: Build merge order

Prioritize by:

1. Blockers first — PRs that other PRs depend on
2. Low risk first — config, docs, cleanup PRs land fast
3. Infrastructure before features — DB/infra PRs before feature PRs that use them
4. Smallest first within same tier — reduces conflict surface

Present triage table to user:

PR Triage
─────────
| # | Title | Risk | CI | Apps | Order |
|---|-------|------|----|------|-------|
| ... | ... | ... | ... | ... | ... |

Proposed merge order: #X -> #Y -> #Z
Proceed? (y/n/reorder)

Wait for user confirmation before proceeding.

Step 1: Per-PR Landing Loop

For each PR in merge order:

1a: Pre-merge checks

# Fresh CI status
gh pr view {number} --json statusCheckRollup,mergeable,reviewDecision

# Check for conflicts with main (PRs merged earlier may cause new conflicts)
gh pr view {number} --json mergeable

If mergeable: CONFLICTING:

• Checkout the branch
• Merge main in (prefer merge over rebase for branches far behind)
• Resolve conflicts (take main for already-landed changes, keep branch for new work)
• Push conflict resolution
• Wait for CI to re-run

1b: Code review

Launch a review sub-agent (or inline review for small PRs <100 lines):

Review checklist:

• Auth/security: new API routes have auth, no IDOR, no injection
• Infra: SST/DynamoDB/Lambda changes noted for deploy
• Code quality: no dangling imports, proper error handling
• Tenant isolation: multi-tenant queries scoped properly
• Data validation: input size limits, cursor validation
• Dependencies: new packages audited

Review verdicts:

• PASS — merge immediately
• PASS WITH NOTES — merge, track notes for follow-up
• FAIL — fix issues on branch before merge, then re-review

1c: Merge

gh pr merge {number} --squash --delete-branch

If branch protection blocks: use --admin if available. If E2E flake (pre-existing, unrelated): merge with --admin after confirming flake is known.

1d: Post-merge sync

# Update local main
git checkout main && git pull

# Check if next PR in queue now has conflicts
gh pr view {next_number} --json mergeable

1e: Track what needs deploy

After each merge, note:

• Lambda/serverless changes -> needs gh workflow run cd.yml
• SST infra changes -> needs manual SST deploy
• DB migrations -> needs prisma migrate verification
• Frontend changes -> auto-deploys via Vercel/CD

Step 2: Deploy Verification

After all PRs merged:

2a: Trigger deploys

# If Lambda changes were merged:
gh workflow run cd.yml -f env=development -f apps={affected-apps}

# Monitor deploy:
gh run list --workflow cd.yml -L 1 --json status,conclusion,databaseId

2b: SST deploy (if needed)

SST infra changes require manual deploy:

sst deploy --stage development

If SST lock exists: sst unlock --stage=development first (requires admin AWS creds).

2c: Post-deploy checks

• Verify CD pipeline completes
• Check for DB migration status if applicable
• Run post-deploy seed scripts if any PR requires them

Step 3: Report

Batch Landing Complete
──────────────────────
Merged: {N} PRs
  - #{number}: {title} ({risk})
  ...

Deploy status:
  - Lambda: {deployed/pending/not-needed}
  - SST infra: {deployed/pending/not-needed}
  - Frontend: {auto-deployed/pending}
  - DB migrations: {applied/pending/none}

Follow-ups:
  - {any PASS WITH NOTES items}
  - {any post-deploy scripts needed}
  - {any remaining open PRs not in this batch}

Error Handling

• Merge conflict cascade: If PR N's merge causes conflicts in PR N+1, resolve before continuing. Don't skip PRs
• CI failure after conflict resolution: Re-run full CI. Don't merge with failing checks (except known E2E flakes)
• Review FAIL: Fix on branch, push, wait for CI, then continue the loop
• Deploy failure: Report immediately. Don't continue to production deploy if dev fails
• GitGuardian false positive: Note and proceed if the flagged secret is pre-existing (not introduced by the PR)

Rules

• Always get user confirmation on triage order before starting merges
• Never force-push during landing
• Merge PRs one at a time, pulling main between each
• Track all infra changes for deploy — don't let SST/Lambda changes slip through un-deployed
• If a PR adds new DynamoDB tables or SST resources, flag for SST deploy
• Known E2E flakes (api-v2:e2e:development connection reset) are not merge blockers
• Use --admin for branch protection bypass only when user has admin rights
• Post-deploy seed scripts must be called out explicitly in the report