Skip to main content

04.15Writing

Summary: Claude Code skill to summarise AI agent replies

Claude Code skill from AR Labs for summarising an AI agent's last reply by progressive zoom: the main point in one sentence, then its parts, strictly nested.

Engraved plate: a three-draw spyglass numbered one to three, and a strictly nested tree opening from it.An engraved three-draw spyglass, sections numbered one to three; from its eyepiece a strictly nested tree opens, one point, then its parts, then theirs.AR LABS · INSTRUMENT CABINET · DRAWER 04CALL NO. 04.150123456789123ABCDFIG. 15 · SUMMARYZOOMSPYGLASSPARTSALevel 1:one sentenceBLevel 2:its two or three partsCLevel 3:theirs, up to threeDStrictly nested,never re-summarisedZOOMS IN ON THE LAST REPLY
On this page
  1. How it works
  2. The judgement it encodes
  3. What exists today
  4. Example

The summary skill is a Claude Code skill, built at AR Labs, that lets a person zoom in on an AI agent's last reply instead of rereading it. Level 1 is the single most important thing in that reply, in one sentence. Level 2 splits that sentence into its two or three significant parts, and level 3 splits each of those into up to three more. Each level decomposes the one above it; none re-summarises from scratch. It is for anyone reading long agent replies who wants the point before the detail. A separate command, /summarize, covers a different need: a short conversational summary of a whole session or a file.

How it works

The target is the agent's immediately preceding message, unless the person names another. /summary gives level 1; /summary 2 or /summary 3 go straight to that level; "go deeper" after a summary moves one level down. Level 3 is the floor: asked to go further, the skill says so and offers a fresh summary of one named branch.

FIG. 01
flowchart TD
  L1["Level 1: the one sentence that matters"] --> A["Component 1"]
  L1 --> B["Component 2"]
  L1 --> C["Component 3"]
  A --> A1["Sub-component"]
  A --> A2["Sub-component"]
  B --> B1["Sub-component"]

The judgement it encodes

Level 1 states content, not a table of contents. "I explained how the auth middleware works and suggested a fix" is wrong. "The auth token expires a millisecond early because the expiry check uses less-than instead of less-than-or-equal" is right. Where the reply argued for something, level 1 is the conclusion, not the topic.

The tree is strictly nested, and parents are repeated word for word. Each part at level 2 belongs to the level-1 claim, not to something else the reply happened to mention. When descending, the exact level-1 and level-2 sentences reappear, so the reader can see what became what.

One sentence per node. No semicolons smuggling in a second point.

Significance, not coverage. Minor material is dropped rather than padding a node. A reply with one real point produces a thin tree, and that is the correct output.

Counts are ceilings, not quotas. A component with only two real parts gets two. The skill never invents a part to reach three.

The tree is the whole reply. No preamble and no offer to expand; the person asks for the next level themselves.

Every sentence stands on its own. If the reply leaned on a term coined earlier in the session or a name that appeared only in tool output, the summary sentence has to make sense without that context.

Thin input gets one sentence. If the last message was a one-line answer or a confirmation, the skill says there is nothing to summarise rather than building three components out of "Done."

The /summarize command writes its account of a session or file in four parts (the situation, what happened, where things stand, what is next) and keeps it under 500 words.

What exists today

The skill is part of our agent setup; it is not released as a separate package. It pairs with Break It Down, which stops an agent overloading a reader in the first place. Both apply the idea set out in cognitive chunking for AI output: a reader holds only a few items in mind at once.

Example

Illustrative example. After a long reply diagnosing a slow page, /summary 2 might return:

The dashboard is slow because it makes one database query per row
instead of one query for the whole table.
 
1. Each of the 200 rows calls loadOwner(), which runs its own query.
2. Batching the owners into one query removes almost all of the
   wait.
3. A query-count test would stop the pattern coming back.