Bayesian

Named for Thomas Bayes: update your priors from evidence. Lenny's self-improvement loop. It learns from its own runs and gets better without a human authoring every skill. The name is a promise: it doesn't merely accumulate skills, it tracks and UPDATES confidence on each one. If it ever stops doing the confidence update, it is not Bayesian. It is just a skill library, and the name would be a lie.

When to run

At a run's merge-ready exit (right after kissinger, alongside gbrain-capture). Reflect on the whole run and distill what it learned. Also run demand once a trap has recurred enough to deserve a standing guard.

The repetition trigger (fires mid-run, not only at exit). Treat the user correcting the same thing twice as a first-class distill signal in its own right. If a preference or correction RECURS across turns or runs, such as "no em dashes" or "worktrees as siblings," the lesson is not sticking. Draft the guard/memory the moment you notice the SECOND occurrence, don't wait for the merge-ready reflection or for N=3. It is the cheapest, highest-signal source of guards Lenny has, because the user has already told you twice. Log it origin: repetition with the two occurrences that fired it. It still obeys the gate below: a style or UX preference is low-risk and self-promotes; anything touching security, destructive actions, or another high-impact path requires human approval like any other guard.

The loop (five steps)

1. Distill. Reflect on the run (from CONDUCTOR-RUN.md + the traps paid): what RECURRED, what false positive kept appearing, what pattern would have prevented a fix, and any correction the user gave twice (the repetition trigger above). If a reusable pattern exists, draft a candidate SKILL.md / guard that is narrow and actionable (procedural memory), distinct from the broad declarative MEMORY.md.
2. Provenance. Mark every auto-drafted skill origin: auto (vs origin: human). The loop may only ever touch its OWN auto-drafted skills. human-authored skills are off-limits to auto-curation, always.
3. Update priors (the Bayesian part that earns the name). Each guard carries a confidence that updates on every application: a hit (fired correctly / was right) raises it; a miss (false-positive / wrong) lowers it. Track hits/misses in a sidecar (e.g. .usage.json), never in the SKILL.md body.
4. Promote via gate. A candidate goes live only when it clears the gate:
   • Auto-promote a LOW-RISK guard after N confident applications (default N=3) at or above a confidence threshold. Low-risk patterns earn their way in without human approval.
   • Human-gate anything touching security, destructive or irreversible actions, credentials, privacy, or another hard safety rail. Those never auto-promote. A guard whose confidence decays below the floor is auto-pruned (archived, not deleted, which keeps the change reversible).
5. Guard forked skills via find-skills. Before ADOPTING a skill from a fork or registry, run find-skills, the shared discovery and vetting front door: search, then scan it (static check for prompt-injection / destructive / exfiltration patterns), apply a trust tier (builtin = trusted; community = blocked on any finding unless the human explicitly overrides), and PRESENT to the human. Never auto-install. The human installs. This is the answer to "forks share skills nobody vetted."

The gate policy (the load-bearing rule)

auto-promote(guard) iff: the guard is NOT security-sensitive, destructive, irreversible, credential-related, privacy-related, or safety-rail touching, AND confidence ≥ threshold across ≥ N distinct confident applications (default N=3). Everything else → human-gate. This is Lenny's own verify-before-trust, pointed at its own evolution: low-risk patterns self-promote so the loop survives a busy or absent maintainer; anything that could cause material harm waits for a human.

Hard rails (orchestration-layer, non-negotiable)

• Config the agent READS, never a runtime it executes. Candidate skills are SKILL.md files plus a confidence sidecar the conductor reads. No engine; that would make Lenny a framework.
• Never auto-touch human-authored skills (origin: human is sacred).
• Never auto-promote a high-impact or safety-rail guard (human-reserved).
• Scan before adopting external/forked skills (trust-tiered).
• An auto-promoted guard is still a HYPOTHESIS. The first time it fires on a real run, its verdict is validated against code like any finding. It can be wrong, and being auto-promoted does not exempt it from that.

Guards (folded from the Rumsfeld + Kissinger passes)

• Hit/miss is judged by an INDEPENDENT signal: a human accepted the finding, an audit confirmed it, or the fix addressed a real bug. NEVER self-assessed. A guard scoring its own confidence is garbage-in; the update is invalid without an external signal.
• Low-risk classification FAILS SAFE. If it is unclear whether a guard touches a high-impact or safety-sensitive path, treat it as human-gate. Uncertainty resolves toward the human, never toward auto-promotion.
• N confident applications = N DISTINCT runs, not N firings within one run. A single-run fluke must not auto-promote.
• Conflict check before promotion. A candidate that contradicts an existing skill, especially a human-authored one, goes to human-gate, never auto-promotes over it.

What this is / isn't

IS: self-improving skill creation plus Bayesian confidence updating, gated. ISN'T: an auto-live skill writer (gate first), a replacement for human authoring (human skills stay primary + untouchable), or a runtime (it's SKILL.md + a sidecar the agent reads).