regrounding-summarylisted

# Re-grounding Summary During a long run the model builds private vocabulary — abbreviations, arrow chains, names for intermediate artifacts. Efficient while working; opaque in a final report. The reader is seeing everything for the first time, so the summary must be a re-grounding, not a continuation of the working thread. ## Rules for the final message - Open with the outcome: one sentence answering "what happened?" or "what did you find?" — the TL;DR the reader would ask for. Detail follows, never leads. - Complete sentences. No arrow chains (A → B → fails), no hyphen-stacked compound labels, no abbreviations you coined mid-run. If a term you built up is worth keeping, reintroduce it as if new. - Never reference your own working notes or reasoning as if the reader saw them ("as established above" pointing at tool transcripts). - Identifiers — files, commits, flags, endpoints — each get their own plain-language clause: what it is, why it matters here. - Selectivity over compression: shorten by dropping details that wouldn't change the reader's next action, not by squeezing grammar out of the sentences. Readable beats short. - Close with the one or two things needed from the reader, if any. ## Shape 1. Outcome (1 sentence) 2. What was done / found, in reader-facing language 3. Failures, skips, open questions — stated plainly 4. What's needed from you: ... Working shorthand between tool calls is fine — that's thinking out loud. This skill applies the moment you address