finish-the-pr

Take the work from its current state to a pull request the reader can merge. The reader may not be watching, so stay active until the handover. If you end your turn while checks are running, the work stops.

Work: $ARGUMENTS. If that is empty, the work in the conversation.

What you may and may not do

• You may commit, push this task's branch, rebase it, fix conflicts, and use --force-with-lease on this branch only.
• Never merge, turn on auto-merge, join a merge queue, push to the default branch or use --admin.
• Never skip hooks. If a hook fails, fix the cause.
• Check the title, body and attachments for secrets and private details before you publish.

Steps

1. Finish the change. If you are on the default branch, make a branch first. Apply /fix-it-properly to a fix.
2. Prove it. Get evidence you saw yourself in this session for every change: the failure before and the pass after, the checks the repo's CI runs, and for UI a look at the running app.
3. Rebase onto the latest default branch. Check that nobody else has already solved this. If another pull request makes this one obsolete, stop and ask.
4. File it. Look at recently merged pull requests and follow their title style. Check that a pull request for this branch does not already exist. Use the format below. Open a real pull request, not a draft, so review bots run.
5. Wait with one watcher (below). Do not write your own polling loop.
6. Handle what comes back. Only act on checks and comments newer than the last push.
   • Check every bot finding against the source. Bots are sometimes wrong.
   • Fix real bugs in the intended case. Prove each fix before you push it.
   • Decline the rest with a written reason, and list them as follow-ups: unneeded tests, guards for cases that do not matter, extra compatibility.
   • Start every comment you post with a line that says an agent wrote it for the reader.
   • Do not let review loops grow the pull request. Prefer the fix that deletes code.
7. Check the gate on the latest commit, then hand over.

Pull request format

Title: why the change matters, not what you touched. "Cut websocket frames by 70%", not "Negotiate permessage-deflate".

<The problem in plain words, from the reader's request. Then the fix in one or two sentences.>

## Proof
Before: <failing output or screenshot>
After: <passing output or screenshot>

## Risk
<What could break, and what happens if it does. Can it be undone: yes or no.>

Add the attribution lines your harness asks for.

Waiting

If nothing has changed, stay quiet. Do not post "still waiting". After each push, start the watcher again. If the default branch moved and touches your files, rebase, push and wait for green again.

The gate

All must be true on the latest commit:

• Your proof covers every change in the diff.
• Required checks are green.
• Review bots have finished, and each finding is fixed or declined with a written reason.
• No human review still asks for changes.
• The branch is up to date with the default branch and has no conflicts.

Asking the reader

A question in a normal message can go unseen. Use the question tool, with the link, what blocks you, and the options with your recommendation first. Ask only when:

• You cannot prove the change.
• The gate cannot pass and you cannot fix that yourself.
• The next step deletes data, touches production, changes things outside the repo, closes a pull request, or force-pushes another branch.
• The goal is unclear in a way that changes the result.

Decide everything else yourself and list those decisions in the handover.

Handover

Start with one verdict, then give the link, the last commit, the proof, what the reviews said, what you decided, and the risks left. State that the pull request is still open and unmerged.