Brief

Produce a rich, visual one-pager — a single self-contained HTML file, designed like a dense dashboard rather than a written document — that lets a time-pressed reviewer understand a body of changes and decide quickly whether to approve or merge them, without reading the diff themselves.

The reader is a busy manager. They may give this 30 seconds or 10 minutes; the brief has to reward both. So the structure is strictly priority-ordered: the highest-stakes, hardest-to-undo changes come first, and the long tail of routine edits comes last. The goal is maximum signal in minimum time — but never trade clarity for brevity. Be thorough; just front-load what matters.

The brief is not a report. It is the equivalent of the PR author sitting down with the reviewer and walking them through the work — anchoring every claim to real code, explaining why the change exists, not just what changed. Most readers will not open the diff. Show them the code that matters, inline.

Two modes — auto-detect

The same skill produces two flavors of brief depending on the state of the work:

• DRAFT — there is a working-tree diff (uncommitted or committed but unpushed) and, typically, a proposed PR stack written out in proposed-pr-stack.md. No real PRs exist yet, or the stack is not yet review-complete. The brief is what the user reads at the approval gate before the work is sliced into PRs.
• FINAL — a real PR stack exists (one or more open/merged PRs), review is complete (PRs are review-clean or all findings triaged), and the user is about to give the merge signal. The brief is what the user reads at the merge gate.

How to pick the mode: look at what exists.