Land

Monitor CI → Resolve reviews → Merge → Monitor production.

This skill takes a PR from "open" to "merged and verified in production." It handles the full landing sequence, including CI polling, review resolution, merge strategy selection, and post-merge production verification.

Input

Accepts one of:

• PR number (e.g. 3021) — looks up repo from cwd or context
• PR URL (e.g. https://github.com/org/repo/pull/3021)
• No argument — finds the open PR for the current branch

Step 0: Resolve PR

If no PR number/URL given:
  branch=$(git branch --show-current)
  gh pr list --head "$branch" --json number,url --jq '.[0]'

Extract: repo, pr_number, branch, base_branch.

Display:

Landing PR #{number}: {title}
Branch: {branch} → {base}

Step 1: Monitor CI

Poll CI checks every 30s (max 10 minutes):

gh pr checks {pr_number} --repo {repo}

Outcomes:

• All pass → proceed to Step 2
• Any fail → read the failing check's logs, diagnose, and attempt fix. Push fix, re-poll
• Timeout (10min) → report status and ask user whether to continue waiting or merge anyway

Display check status on each poll (only changed states).

Step 2: Resolve Reviews

gh pr view {pr_number} --repo {repo} --json reviews,comments,reviewRequests

Outcomes:

• No reviews/comments, no review requests → proceed to Step 3
• Pending review requests → notify user, ask whether to wait or proceed
• Review comments exist → read each comment, assess if actionable:
  • Codex/bot suggestions: evaluate and apply if valid, push fix
  • Human comments: summarize for user, ask for guidance
  • Approved with no blocking comments → proceed
• Changes requested → summarize feedback, attempt fixes if code-related, push, re-request review

After resolving, re-check CI (fixes may have broken something).

Step 3: Merge

Determine merge strategy:

• Default: --squash (clean single commit)
• If branch has meaningful commit history user wants preserved: --merge
• If user specified: use their preference

gh pr merge {pr_number} --repo {repo} --squash --delete-branch

If branch protection blocks merge:

• Check if --admin is available (user has admin rights)
• If yes: use --admin flag
• If no: report the blocking requirement and ask user

Verify merge:

gh pr view {pr_number} --repo {repo} --json state,mergedAt,mergeCommit

Step 4: Monitor Production

Post-merge verification. This step is context-dependent — the skill adapts based on what was changed.

4a: Identify what to monitor

From the PR diff, determine:

• Lambda/serverless changes → check if SST deployment is needed (code on main ≠ deployed)
• Database changes → query for expected state changes
• API changes → test endpoints
• Frontend changes → check deployment status (Vercel, etc.)

4b: Execute monitoring

For Lambda changes ({PRODUCT} pattern):

• Note: merging to main does NOT auto-deploy Lambda. SST deployment is separate
• Query DB for expected state changes (e.g. stale messages expiring)
• Check CloudWatch logs if accessible
• Report: "Code is on main. Lambda redeploy needed for changes to take effect"

For deployed services (Vercel, etc.):

• Check deployment status: vercel ls --scope {team} or GitHub deployment status
• Verify the deployment completed
• If accessible, hit a health endpoint or verify the change visually

For database/data fixes:

• Run verification queries to confirm expected state
• Compare against baseline captured before merge

4c: Report

Landing Complete
────────────────
PR: #{number} merged → {merge_commit[:8]}
CI: All {N} checks passed
Reviews: {resolved|none}
Merge: squash → {base_branch}
Production: {status}
  - {monitoring_detail_1}
  - {monitoring_detail_2}

If production verification reveals issues, flag immediately and offer to investigate.

Error Handling

• CI flake: If a check fails but the failure looks transient (network timeout, flaky test), offer to re-run: gh run rerun {run_id} --repo {repo} --failed
• Merge conflict: gh pr view shows mergeable state. If conflicted, report to user — don't attempt auto-resolution
• Rate limiting: If gh commands hit rate limits, back off and retry with increasing intervals

Rules

• Never force-push during landing — the PR branch is shared state
• Never skip CI checks without explicit user approval
• Always verify merge succeeded before reporting completion
• If production monitoring reveals a regression, prioritize flagging over completing the skill
• Respect repo-specific merge policies ({PRODUCT}: bun run pr:create for creation, but gh pr merge for merging is fine)