Let It Merge

---
name: let-it-merge
description: >
  Verify a change to a fixed bar and merge it without a human review step.
  Use when the user says "let it merge", "merge it if it's good", "you have
  merge rights", "ship it if tests pass", or runs /theo-mode merge. Only for
  repos with a real pr -> main -> staging -> prod flow; never a direct path to
  production.
---

# Let It Merge

Goal: the change is on main, and there is a written record of exactly what
was verified. Trust is earned per merge, not assumed.

## Preconditions (check these, do not assume)

1. Main is not production. Confirm there is a staging or preview environment
   between main and prod (`gh workflow list`, deploy configs, CLAUDE.md). If
   main deploys straight to prod, stop and say so. This mode does not apply.
2. Branch protection exists and CI is required. `gh api
   repos/{owner}/{repo}/branches/main/protection` or the repo settings. If
   there is no CI, there is nothing to trust; stop.
3. You can actually merge: `gh pr merge --help` works and you are not blocked
   by a required reviewer you cannot satisfy.

## The bar

A PR merges only when ALL of these are true, and you write them down in the
PR before merging:

- CI is green on the exact commit being merged, not a previous one.
- You ran the change yourself, not just its tests. For UI: a screenshot
  after the change. For an API: a request/response. For a library: an
  import-and-call. Attach the evidence as a PR comment.
- The diff does what the title says and nothing else. No drive-by refactors,
  no unrelated dep bumps. If there are, split them out first.
- No migration, auth, billing, or data-deletion code. Those always get a
  human. Say so and stop.
- The PR is under ~400 lines changed, or the user explicitly raised the cap.
- Rollback is one revert commit away. If the change cannot be reverted
  cleanly (schema changes, one-way data transforms), it needs a human.

## Process

1. `gh pr checkout N`. Rebase on main if behind. Push if you rebased.
2. Wait for CI on the new head: `gh pr checks N --watch`.
3. Run the change. Collect evidence.
4. Post a comment titled "Merge verification" with: CI run link, what you
   ran, what you saw, the rollback command.
5. `gh pr merge N --squash --delete-branch` (or the repo's style).
6. Watch the post-merge pipeline for one cycle: `gh run list --limit 3` and
   the staging deploy if there is one. If it goes red, revert immediately and
   report.

## Report

PR URL, merge commit, verification comment link, staging status. One line
each. If you did not merge, the single precondition or bar item that failed.

## The roll-the-dice clause

Theo's advice is "maybe roll the dice a bit", after you have gotten used to
the model. This skill takes that literally: the dice are loaded by the bar
above. Widening the bar (bigger PRs, skipping the run-it-yourself step) is a
decision the user makes in their own words, and it is recorded in the
verification comment when they do.