bfollington Skill Improver
Skills improve from friction, not from review. The question is never "could this skill be better" — everything could. It is what actually went wrong, and would a change to a skill have prevented it?
Most friction should not become a skill change. It was environmental, or a one-off, or already covered by something that simply did not fire. Changing skills in response to noise is how a sharp set becomes a bloated one, and bloat is the failure mode that matters here — every unnecessary line makes the necessary ones less visible.
Start from what actually happened
Not "how did that go" but: where specifically was there confusion, repetition, a wrong turn taken and reversed, a workaround invented, or a correction from the user?
Each of those is a candidate. For each, the question that decides everything: would a skill have prevented this, and which one?
Usually the answer is one of:
- A skill existed and did not fire. The problem is the description, not the body. Fix the trigger.
- A skill fired and was ignored or misapplied. The content is not landing — usually buried, hedged, or stated so generally it did not connect to the situation.
- A skill was right but incomplete in a way that recurs. A real gap.
- No skill covers this, and it will happen again. Possibly a new skill.
- Nothing would have helped. Environmental, novel, or genuinely one-off. This is the most common answer and it is a fine one.
Has it happened twice?
A single occurrence is an anecdote. Skills written from one incident encode a situation that may never recur, and they cost context on every load thereafter.
Twice is a pattern worth encoding. Once is worth remembering and watching for.
The exception: a single failure that was expensive or would have been irreversible. Those earn a change on first occurrence.
Prefer cutting
The reflex after a failure is to append a clause covering it. A few rounds of that produces something long, hedged, and no longer sharp — and the appended clauses are the least-read part of any skill.
So ask first: would the existing principle, stated better, have covered this? Usually yes. Then the change is a sharper sentence, not an extra one — and the skill gets shorter while getting stronger.
Additions should be rare and should earn their line. Ask what would be cut to make room, and if nothing can be, question whether the addition is really needed.
The strongest improvement available is usually a new failure mode at the bottom of an existing skill: one line, high density, naming a trap that was just fallen into.
Fixing triggers
A skill that did not fire is not fixed by improving its content. Nobody read it.
The description needs the situation in the words it actually arrives in — the phrasing the user really used, not the topic in the abstract. And a negative case, because a skill that fires everywhere is noise and gets ignored, which is the same as not firing.
What to say
Keep it short and specific: what happened, which skill, whether it recurs, what one change, and whether that change is a cut or an addition.
If nothing is worth changing, say that. A reflection that ends in "no changes needed" is a successful reflection, and much better than one that invents work to justify itself.
Failure modes
- Reflexive reflection. Running this after every task, generating small changes that accumulate into bloat.
- Improving from imagination. Proposing changes for situations that did not occur.
- Appending forever. Every friction becomes a new clause. Nothing is ever re-cut.
- Fixing the body when the trigger is broken. Rewriting content nobody loaded.
- Manufacturing findings. Producing a list because a list is expected.
- New skill for one incident. A permanent context cost for a situation seen once.