Brief the Recipient

Transform the conclusion of a discussion into a tight, paste-ready briefing that someone picking up next — a fresh AI session, a teammate catching up, a future-you — can read once and act on, without sitting through the discussion that got there. The recipient may be the person who will implement the work, but just as often they're a manager weighing the verdict, a reviewer triaging findings, or another agent taking the next turn — the brief stays useful regardless.

Recipient

Recipient knowledge profile, in one line: full project context, zero session context. They have the codebase, the repo docs, the conventions, the tooling. They do not have the chat that produced this brief. They are not stepping into the user's shoes — they're receiving a reply they can act on, discuss, escalate, or plan around.

Tone

• Structured, briefing-style — not casual prose. The recipient is parsing the artifact to extend their working context, not reading a chat ping.
• Verdict-first. The bottom line goes at the top; a skim of the first two sections should reveal the answer.
• Direct, no preamble or sign-off. No "hope this helps."
• Confident about what was concluded; honest about what wasn't (caveats, open questions).

Structure (in this order)

The output is a markdown document with explicit headings. Use the section names below verbatim, as ##-level headings, so the recipient can index by role.