Ai Ship

---
name: ai-ship
description: >-
  Lands the work: one commit per change, the changelog entry, a pull request that opens
  with what changed in plain words, the production-ready boxes ticked with the command that
  ticked each, the work item closed by a keyword in the body, and the branch cleaned up
  afterwards. Trigger for "ship it", "open a PR", "I'm ready for review", "commit this",
  "merge it". Not for judging the diff — use /ai-review first. Not for writing the spec —
  use /ai-spec. Not for finding the bug — use /ai-debug.
license: Apache-2.0
compatibility: needs git; needs gh for the pull request
disable-model-invocation: true
---

# Land the work

## What it produces

Commits, a changelog entry, a pull request on `origin/<branch>`, and a branch that gets deleted after it merges.

## Steps

1. Run the repository's own gate — the recipe set CI runs, whatever it is called here —
   and show its output. Not a summary of it — the output. If it is red, stop here;
   nothing below this line is worth doing.
2. Commit in the shape the change actually has: one commit, one change. A commit that
   needs the word "and" in its subject is two commits. Subject is
   `<type>(<scope>): <what changed>`, imperative, and the body says why rather than what.
   Never `--no-verify`: the hooks are the floor, and what they would have said is the thing
   that needs fixing.
3. Update the changelog. A breaking change is written as a breaking change, in the words
   somebody upgrading would search for.
4. Tick the production-ready boxes in the spec. Assertion 19 reads what is beside each
   tick, so a box with no command in backticks and no `not applicable` fails the gate.
5. Open the pull request. The first paragraph is what changed, in plain words, for somebody
   who does not code. Then the spec link, then what to look at first, then what you are not
   confident about — that last section is the one reviewers use most.
6. If the spec's frontmatter has a `ref`, append the closing keyword to the body:
   `Closes owner/repo#45` on GitHub, `Fixes #45` on Azure Repos, `AB#45` where the Azure
   Boards app bridges the two. One constraint catches people: the pull request must target
   the default branch, or the keyword is ignored and nothing is linked or closed.
7. After it merges, delete the branch, and say in one line what is now true that was not
   true before.
8. A conflict is resolved by intent and never by taking a side. Read what each side was
   trying to do, say it in the merge in one line each, and keep the change that serves both
   — or stop and ask, because a conflict resolved by whoever pushed last is a decision
   nobody took. `/ai-debug` owns finding the cause when the merged result then misbehaves.

## Done when

- The gate is green and its output is in the conversation.
- The pull request explains itself to somebody who was not here.
- Every production-ready box is ticked, each beside the command that ticked it.
- The pull-request body carries the recap page's link when one exists, so the reviewer
  opens the record of the range before the diff.

## What this is not

Not a place to fix review findings quietly. A finding gets its own commit, with its own
message, so the diff of the fix can be read on its own.

- "The change is tiny, so one commit that says the whole thing is enough" — one commit per change: a subject that needs the word 'and' is two commits, and a finding gets its own commit so its diff can be read on its own.