/GROK : An Agent Skill for Narrative Summaries

---
name: grok
description: ">"
  Re-tell your own last reply as 2 or 3 short narrative paragraphs, so the point survives without the
  scaffolding. Invoke for "/grok", or when the user asks you to say that again plainly, give them the
  short version, or explain what it actually means. It re-expresses what you ALREADY said: no new
  research, no tool calls, no fresh findings. Prose only, no headers, no bullets, no tables.
---

# /grok: say it again, as a story

Your last reply was structured for completeness. This one is structured for understanding. Take what you
just said and re-tell it in **2 or 3 short paragraphs of plain narrative prose**, as if explaining it to a
capable colleague who missed the detail and wants the shape of it.

## What to re-tell

**Your own previous reply, and nothing else.** Not the whole conversation, not the task, not a fresh look
at the code. If your last message was itself a `/grok` response, go back to the one before it. If the user
typed `/grok` with a topic after it, narrow to that thread within your last reply.

**Add nothing.** No new investigation, no tool calls, no findings that were not already in the reply. If
you notice something new while re-reading, that is a separate message, not part of the grok. The value
here is compression and clarity, and a grok that smuggles in fresh claims is neither.

If the last reply was already two plain paragraphs, say so and stop rather than paraphrasing it into
something worse. If there is no previous reply of yours to work from, say that instead of inventing one.

## How to write it

**Narrative means causal, not chronological.** Not "first this, then that." Say what was true, what that
caused, and what it means now. A reader should finish knowing the shape of the situation, not a list of
events. Lead with the thing that matters most, which is often the surprise, the reversal, or the decision
waiting on them, and let the rest hang off it.

**Strip the scaffolding, keep the load-bearing detail.** Out: file paths, line numbers, commit hashes,
counts, tables, headers, bullets, bold labels. In: any specific that carries the meaning. "The reconcile
bot published it overnight" needs no commit hash to land, but "nobody is on it" and "this breaks at the
$5 price" are the substance and must survive.

**Two or three paragraphs, short ones.** If it will not compress that far, the compression is the point:
choose what matters and drop the rest rather than writing four dense paragraphs. Plain sentences. No
em dashes or en dashes.

## What must survive the compression

These are the things a summary is most tempted to smooth away, and losing them makes the grok actively
worse than the reply it replaced:

- **Anything waiting on the user.** A pending decision, an unanswered question, a required approval. If
  they read only the grok, they must still know what is theirs to do.
- **Corrections and reversals.** If the last reply corrected an earlier claim, admitted an error, or
  withdrew something, that stays. Narrative flow is not a reason to quietly drop the part where you were
  wrong.
- **Uncertainty, as uncertainty.** What was unverified stays unverified. Never let compression promote a
  hedge into a fact; "this looks like" must not become "this is".
- **Bad news.** A failure, a live bug, a thing that did not work. If the reply led with a problem, the
  grok leads with it too.

A grok that reads better than the reply because it left out the awkward parts is a failure, not a success.