itaywol Self-improve: turn lessons into skills
adept skills are portable memory. A lesson written as a skill is loaded by every harness on every future session — not lost when this context ends. When you learn something durable, capture it instead of forgetting it.
When to capture
Capture when the lesson is durable and reusable, not one-off:
- The user corrects you ("we always use X, not Y", "don't touch Z").
- A fix or pattern generalizes beyond the file you're in.
- You discover a project convention the code doesn't make obvious (a build gate, a naming rule, a required pre-PR step).
- You catch yourself thinking "I'll remember that for next time." — you won't; the skill will.
Don't capture: secrets, one-shot facts, anything already obvious from the code or
existing skills. Improve an existing skill before adding a near-duplicate (adept skill list).
The loop
adept skill list # does a skill already cover this? edit it if so
adept skill add <kebab-id> --edit # else scaffold a new one
# write a triggering description + a tight, harness-neutral body
adept sync # render to every enabled harness
adept status && adept diff # confirm it landed clean
Then tell the user, in one line, what you captured and where — they own the memory, so let them veto it. Commit the new skill with their normal review.
What makes a captured lesson good
- Description = trigger. Front-load when it applies so a future agent loads it at the right moment. See [[authoring-adept-skills]] for crafting the description and activation.
- Atomic. One lesson per skill. If it needs "and also…", it's two skills.
- Reason, not just rule. "Use sentinel errors so callers can
errors.Is" beats "use sentinel errors" — the why survives refactors the rule wouldn't.
Confirm before you persist
Capturing is an outward, durable act: it changes how every future session behaves. Surface what you're about to write and let the user confirm — don't silently rewrite the project's shared memory. See [[using-adept]] for the surrounding CLI.