mergekit

The other half of a pull request's life. Something else opened it, whether you, an agent, or a teammate; mergekit is what you run when it is your turn to judge it, and what you run when your own PR comes back needing changes. It gets the PR into a git worktree, reusing the one the branch already lives in when there is one, gets the project running, and prints a review pack of everything you need to form an opinion. Then it waits. When you say merge, it merges; when it needs changes, it fixes them in the worktree you already have open.

mergekit is the one skill permitted to merge a pull request, a deliberate exception to the "never merge without an explicit ask" rule the rest of a PR toolchain holds. That permission is earned by a single hard precondition, stated in Never merge automatically: a human confirms that specific PR, every time. Without the confirmation, mergekit has no more authority than any other skill.

It forms no opinion about the code. Judging the source is a code-review job; mergekit sets the review up and executes the decision you reach.

When this fires

The PR already exists, and you are either reviewing it, or you authored it and it has come back needing changes:

• list. "What PRs are waiting on me", "show me the ready-for-review PRs", "mergekit list".
• start <n>. "Pull PR #34 down so I can test it", "set up #34 for review", "check out this PR for QA". <n> is a PR number by default, in every mode here.
• close <n>. "Merge #34", "this one's good, land it", "#34 needs changes: ".
• fix <n>. The author's side: "my PR is red, fix the CI", "address the review comments on #34", "respond to the feedback on my PR". It triages the feedback before acting on it; it does not apply every comment on sight.

If a PR is named but the action isn't, assume start, because setting a PR up is safe and reversible while merging is not.