self-learning

name	self-learning
description	Use after any correction, mistake, discovery, or fix — capture the lesson durably into cerebrum + buglog so the same discovery is never repeated. Closes the improvement loop that makes the team better across sessions.
origin	SkyyRose

Self-Learning

A lesson that lives only in the transcript dies with the session. The next agent — or the next you, three hours from now — re-derives the same discovery, re-trips the same gotcha, re-asks the founder the same question. This is the OpenWolf Cerebrum Learning protocol, and it is MANDATORY every session, not a nice-to-have: every correction, non-obvious convention, gotcha, and technical decision gets written down where the next session will actually see it. The bar to log is LOW — a slightly redundant entry costs nothing; a missing one costs the whole rediscovery.

Boot first: read .wolf/cerebrum.md and .wolf/buglog.json before re-deriving anything — the fix or preference may already be recorded.

When to Use

• After any user correction ("no, do it this way instead") or rejected suggestion.
• After any mistake, bug, failed test, failed build, or user-reported problem.
• After any discovery: a non-obvious project convention, a framework pattern, an API that surprised you, a dependency quirk, how modules connect.
• After a fix — the fix is only half the job; the lesson is the other half.
• Any file edited more than twice in one session — that pattern itself is a signal something was misunderstood and belongs in Do-Not-Repeat.

Method

1. Classify the lesson — which store, which section:
   • .wolf/cerebrum.md → User Preferences — style, naming, workflow, a rejected suggestion.
   • .wolf/cerebrum.md → Key Learnings — a convention, framework pattern, API surprise, dependency quirk, how modules connect.
   • .wolf/cerebrum.md → Do-Not-Repeat (WITH DATE) — a mistake made or a gotcha that would trip up a fresh session.
   • .wolf/cerebrum.md → Decision Log — a significant technical choice + the "why", especially when the founder explains a trade-off.
   • .wolf/buglog.json — any error / failed test / failed build / user-reported problem, with error_message, file, root_cause, fix, tags.
   • tasks/lessons.md — behavioral corrections (how Claude should act), separate from engineering facts.
2. Write it. For a new buglog entry, allocate the ID via python scripts/wolf_bug_id.py — never guess or reuse an ID from memory (manual guessing has already caused cross-session ID collisions). If the same defect recurs, bump occurrences + last_seen on the existing entry instead of duplicating it.
3. Sync recurring bugs. Any buglog entry reaching occurrences >= 2 must run python scripts/wolf_recurring_sync.py — it regenerates the 1-line recurring-issues digest between the wolf:recurring markers in CLAUDE.md so every future session loads it automatically without re-reading the full buglog.
4. Commit fix + lesson together. Per CLAUDE.md's After-a-Mistake protocol: fix it → name the lesson in one sentence (what was wrong + why) → write the rule that prevents recurrence → commit the fix and the lesson in the same change.

Loop until the lesson is durable

Bounded — same discipline as [[drive-to-green]], never more than a few turns per lesson, stop if the same write fails twice (that's a tooling problem, not a retry problem):

1. Extract the lesson from what just happened (correction, error, discovery).
2. Write it to the classified store (cerebrum section, buglog, or lessons.md).
3. Re-read the entry to confirm it landed — see Verify below.
4. Apply it: the next action in THIS session already reflects the new rule.

Verify from an authoritative source

A learning is real only when it is written and re-readable — never assume the write succeeded because the Edit/Write tool didn't error:

• Re-read after writing. Open .wolf/cerebrum.md or .wolf/buglog.json again and confirm the new entry is present, in the right section, with the right shape. An intention stated in a reply is not a lesson.
• A Do-Not-Repeat rule must be concrete and checkable, not a vague intention — "don't guess buglog IDs; run scripts/wolf_bug_id.py" is checkable, "be more careful with IDs" is not.
• Use scripts/wolf_bug_id.py for every new bug ID — never guess. This exact gotcha (manual ID guessing → collisions) is itself a Do-Not-Repeat entry; don't re-earn it.
• Cite the entry — quote the actual cerebrum line or buglog JSON you wrote, not a paraphrase of what you meant to write.

Adversarial pass

• [[adversarial-verification]] — did the lesson actually get written, or only intended? Default to "not durable yet" until the re-read in the Verify step independently confirms the entry exists. A session that says "I've noted this" but never touched .wolf/cerebrum.md or .wolf/buglog.json produced nothing.

Guardrails · Handoff · Log

• The bar is LOW. When in doubt, log it — a false-positive entry costs nothing; a missed lesson repeats the mistake, possibly at production cost.
• This skill is the substrate every pod's self-heal loop writes back to: per CROSS-PLUGIN.md's handoff graph, any plugin → skyyrose-qa:drive-to-green → skyyrose-core (memory log) — skyyrose-core owns cerebrum/buglog discipline, and self-learning is where that write happens.
• Cross-ref [[memory-system]] (the read/write substrate this skill writes into), [[self-healing]] (the loop that triggers most of these writes), and [[continuous-learning]] (extracting reusable patterns beyond single-session fixes).