merge-briefinglisted

# merge-briefing ## Overview A merge is irreversible shared state, so it is gated on the user's explicit per-PR answer. The gate is cheap to satisfy formally and easy to satisfy falsely: the honest version needs a probe wide enough to support "nothing is open", and the surface where blocking findings actually live — inline review threads — is the one a natural-looking `gh pr view --json comments,reviews` call silently omits. This skill is the on-demand home for that procedure. The *Pre-Merge Reporting* rule ([`ETHOS.md` → Rules praxis carries](../../ETHOS.md#rules-praxis-carries)) keeps the gate; the six-part list in Step 4 below is the report's shape; the steps below are how you get from "the PR looks done" to a question the user can answer in one word. **Core principle:** the briefing is a claim about the PR's state, so every line in it is probed at compose time — not recalled from when the PR was opened. ## When to Use - About to ask the user to approve a merge. - A merge was requested and you have not yet surfaced a briefing this turn. - Re-asking after a previous ask went unanswered, or after CI/review moved. - A companion, follow-up, or regenerated PR is next in a cluster the user already approved once. ## The Iron Law - **One PR, one briefing, one answer.** Approving PR X approves only X. - **Compose the briefing from this turn's probe output.** An entry-time `CLEAN` status is not permanent; a stale anchor makes the user discover a conflict you should hav