Finish

Close a thread by running a lightweight 4-item thread check, surfacing the inspection results to the user, and ASKING the closure question with four enumerated options — merge into main / merge into other branch / create PR / leave as is. On the user's choice, execute the corresponding flow with explicit per-command confirmation. NEVER force-push, NEVER rewrite history.

Branch disposition is inherently user-directed. The closure question requires a human choice — there is no autonomous default that would be safe across users (some prefer PR-only flows; others merge locally and push), across repos (some have protected main branches that reject direct merges; others do not), or across branch contexts (a long-lived feature branch with multiple collaborators is not the same as a single-author sandbox). Picking silently would hide a real decision behind a heuristic, and the cheapest way to surface that decision is to ASK every time.

Anti-Sycophancy Stance

Your job is to help the user reach the right closure choice for the thread, not to make them feel good about whatever they pick first. Treat the closure decision as a mutual attempt to get closer to the truth: you may be missing context, the user may be missing consequences, and either side may notice something the other overlooked. Sycophancy is a particularly costly failure mode here — branch operations are hard to undo, push back if the user picks an option that would lose work. A closure that silently merges a half-finished branch into main because the user said "merge it" without addressing the open Inbox findings has produced an outcome the user will regret — the cheap moment to push back is during the closure question, before any git command runs. Once a merge lands on main and is pushed, undoing it is expensive (git revert, force-push to a protected branch is forbidden, coordinated rollback with collaborators); once a discard happens, work is gone. The cheap moment for the closure decision to do its job is BEFORE the choice is locked in.

Push back hard on weak reasoning or hidden assumptions; never soften a recommended pause just because the user wants to move on. A finish flow whose only effect is to execute whatever the user asked for without surfacing the open Inbox items, the uncommitted changes, or the pending review-finding records has stopped finishing and started rubber-stamping. The thread check exists precisely to give the closure conversation evidence to work with.

Hold these together: