Retro
Skill nubasu/Pseudo-Fable-Framework/frameworks/pseudo-fable-retro/.claude/skills/retro
Written by Fable, for models that aren't — context frameworks that lift Opus/Sonnet-class agents to Fable-grade work discipline.
npx -y skills add nubasu/Pseudo-Fable-Framework --skill retroAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 0 stars0 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.
What its author says it does
Copied from the file, not written here
Harvest lessons and grow the rule set — after a milestone, a bounce, or a failed-fix spiral, extract what failed or dragged, identify the missing sentence that would have prevented it, route it to the narrowest effective home (Gotchas / project CLAUDE.md / store templates / memory / nowhere), and periodically prune rules that never fire. Use at milestone completion, after any bounce or reclaim, after an incident, and ~weekly for rule inventory.
SKILL.md
3.5 KB, 707 tokens by cl100k_base, as published. Nobody here has run it
retro — rules are grown from failures, not ideas
The family's premise: every rule must earn its context cost. This skill is the mechanism that adds the ones that will, and removes the ones that stopped.
1. Harvest — what actually went wrong or dragged?
Scan the just-finished work for:
- Failures — bounces, reverts, finish-gate findings, assumptions that survived too long before being falsified.
- Drag — anything that took ≥2 attempts; rediscovery of a trap somebody (possibly you) already knew; questions whose answers existed somewhere unread.
- Surprises — "I didn't expect X". A surprise is an unpriced risk; price it now.
For each: one line — what happened, and the moment it became inevitable.
2. The missing sentence
For each item, ask the family's question: which single sentence, present in which document, would have prevented this?
- If you cannot phrase the sentence, you have not understood the failure yet — dig once more (root-cause thinking applies to process failures too).
- If the sentence would not actually have been read at the moment it was needed, it is the wrong sentence or the wrong home — fix that, not the wording.
3. Route — the placement table
Default to the narrowest scope that still catches the recurrence; a rule in too broad a home is noise for everyone else.
| Lesson scope | Home |
|---|---|
| This repo's concrete trap (flaky test, generated file, odd build step) | Project CLAUDE.md / AGENTS.md — Gotchas or Project specifics |
| A trap delegated workers keep hitting | The PL's standing brief Gotchas (pseudo-fable-orchestrate delegate §3) |
| This project's recurring process failure | Project CLAUDE.md — as a rule WITH a trigger |
| Generic — would recur in any project | The store's framework templates: propose the edit to the user (the store is shared across projects — never edit it silently), bump the version comment |
| About the user's preferences or workflow | Agent memory, if the harness provides one |
| One-off, unlikely to recur | Nowhere. Not every lesson deserves a rule — note it in the task report and let it go. |
4. Prune — rules must keep earning their place (periodic inventory)
- Walk the project CLAUDE.md rules and Gotchas. For each: has it changed behavior recently?
- Never fired since added, and ≥~10 tasks have passed → delete, or demote to a comment.
- Fired wrongly (overhead without catching anything) → rewrite the trigger, or delete.
- Unsure? Keep a rough tally in the state file:
rule → last fired: <task/date>, and decide next inventory.
5. Constraints — retro's own failure mode is rule inflation
- Add at most 2 rules per retro. Harvested five lessons? Keep the two with the highest recurrence-probability × cost; report the rest as observations.
- Every added rule ships with: a trigger (when it fires), an action, and the failure it prevents (one line, as a comment or ledger note).
- Deleting a rule is as valuable as adding one. A retro that only ever adds is broken.
Gives 0 of the 12 instructions most memory context skills give in 707 tokens
Counted across 674 of the 847 authors here whose files we hold, read 2026-08-06
- inform the user when setup is completein 21 of 674, across 6 files
- confirm the draft with the user before writingin 21 of 674, across 6 files
- update the agent skills block in place if it existsin 21 of 674, across 6 files
- present findings to the userin 20 of 674, across 5 files
- write the three docs files from seed templatesin 20 of 674, across 5 files
- ask the user about each decision one at a timein 19 of 674, across 4 files
- edit CLAUDE.md if it existsin 18 of 674, across 3 files
- explore current repo statein 18 of 674, across 3 files
- do not overwrite user edits to surrounding sectionsin 18 of 674, across 3 files
- back up the original file before overwritingin 16 of 674, across 8 files
- keep the memory index under 200 linesin 15 of 674
- Provide actionable steps and verificationin 13 of 674, across 2 files
Said here and by no other author read
- scan finished work for failures, drag, and surprises
- find the single sentence that would have prevented a failure
- route each lesson to the narrowest effective home
- propose store template edits to the user
- prune rules that never fire periodically
- add at most two rules per retro
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.