Draft 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 in-progress changes and decide whether to approve them, without reading the diff themselves.

The reader is a busy manager. They might give this 30 seconds or they might give it 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 away clarity to save the reader a few seconds. Be thorough; just front-load what matters.

When this runs

• As part of a shipping workflow: once a body of work is implemented but not yet approved — typically when an agent has a working-tree diff and a proposed PR stack and is about to ask the user to approve the breakup. The brief is the thing the user reads at that approval gate.
• Standalone: any time someone wants to review uncommitted work before approving it.

Voice — make it read like a story

A page of tables and callouts is quick to skim but hard to truly absorb: the reviewer gets facts without the thread that connects them. So beyond being well-structured, the brief should read — like walking a colleague through the change, not filing a report.

• The TL;DR is a genuine narrative opener: a few plain sentences telling the story of this change — the problem it addresses, what was done about it, and what's worth a careful look.
• Every section opens with a one- or two-sentence plain-prose lead-in that frames what follows and ties it back to the whole. The dense table or callout list then sits beneath that lead-in.
• Prefer plain, connected sentences over terse fragments.