Regrounding summary

Skill kpab/claude-fable-5-skills/skills/regrounding-summary

Make Claude Fable 5's final report readable to someone who saw none of the work. Use for long agentic sessions, overnight runs, and multi-tool tasks — whenever summaries come back as arrow-chain shorthand, invented abbreviations, or references to reasoning the reader never saw. Pair with grounded-progress for status content; this skill governs the prose.From its SKILL.md

Install

npx -y skills add kpab/claude-fable-5-skills --skill regrounding-summary

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

1.9 KB, 330 tokens by cl100k_base, as published. Nobody here has run it

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

Outcome (1 sentence)
What was done / found, in reader-facing language
Failures, skips, open questions — stated plainly
What's needed from you: ...

Working shorthand between tool calls is fine — that's thinking out loud. This skill applies the moment you address the human.

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.

Gives 0 of the 12 instructions most docs writing skills give in 330 tokens

Counted across 1,951 of the 3,904 authors here whose files we hold, read 2026-09-06

Use third-person for skill descriptionsin 54 of 1951, across 35 files
Start descriptions with Use whenin 43 of 1951, across 29 files
Run baseline scenarios before writing any skillin 40 of 1951, across 26 files
Use active voicein 40 of 1951, across 36 files
Map file responsibilities before defining tasksin 36 of 1951, across 29 files
Use checkbox syntax for tracking stepsin 35 of 1951, across 27 files
Ask one question at a timein 35 of 1951
Offer execution options after saving the planin 33 of 1951, across 24 files
Include complete code in every stepin 33 of 1951, across 27 files
Design units with clear boundaries and interfacesin 31 of 1951, across 23 files
Announce the skill usage at the startin 30 of 1951
Verify agent compliance after adding the skillin 29 of 1951, across 17 files

Said here and by no other author read

Open with the outcome
Reintroduce coined terms as if new
Describe identifiers in plain language
Prioritize readability over brevity
Close with required reader actions

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.