brief-me

Brief Me

The user has come back to this session with weak or no memory of it. Reading the last message will not fix that: the last message was written for someone who was here five minutes ago. It leans on pronouns, on shorthand coined mid-session, and on file names introduced hours back. It continues the thread; it does not introduce it.

Produce one short briefing that puts them back in the chair. Then stop.

1. Check the state before you narrate

The failure mode of this skill is a fluent, confident, wrong story. Guard against it by reading the real state first, not your memory of it:

• git status and git diff --stat against the base branch — what is actually changed, and is anything half-applied?
• git log for recent commits, and the current branch name.
• Any plan, spec, or todo file written during this session, and the active todo list.
• Whether tests were run, and what they said.

Then hold two categories apart as you write. A claim backed by disk or git is stated flat. A claim recalled from the conversation and not checkable is marked as recalled, with the check named. Never assert a piece of work is finished without confirming the file exists.

2. The brief

Six headings, in this order. The whole thing fits on one screen.

In one line — the entire session in one sentence a stranger could follow.

What we're doing — the goal in plain terms, one or two sentences. This thread, not the codebase.

Where we got to — the arc so far. Up to five bullets. Completed work only.

Right now — the frozen frame. What is on disk this second. Say loudly if anything is half-applied or the working tree is incoherent; coming back to a partly-finished multi-file edit is the case that hurts most. Note when tests last ran and what happened.

Waiting on you — split three ways, dropping any that are empty:

• Decide — genuine decisions, each with your recommendation.
• Tell me — information you cannot find for yourself.
• Do — anything only they can perform: a login, a deploy, an approval.