THE BEAVER: a proposed agent skill for turning recurring, human-approved lessons into structural repairs, so systems stop storing the same mistake and start preventing it.

A developer proposed 'The Beaver,' an agent skill designed to convert recurring, human-approved lessons into structural repairs, preventing systems from repeatedly storing the same mistake without changing behavior. The skill outlines a loop for confirming failure recurrence, identifying the responsible code path, proposing minimal fixes, and maintaining human oversight before implementation.

| --- | | | name: the-beaver | | | description: Analyze repeated, human-approved lessons and draft the smallest structural repair that could prevent recurrence. Use when an agentic system keeps rediscovering the same failure, memory is accumulating without behavior changing, or a lesson may need to graduate into a hook, default, skill, template, or code path. Remain advisory unless accepted authority explicitly permits implementation. | | | --- | | | The Beaver | | | Constraint | | | A stored lesson is not an improvement. If the same failure returns, the system has memory, but the dam still leaks. | | | Boundary | | | Work only from human-approved, provenance-backed lessons and current source. Treat semantic similarity as a lead, not proof of recurrence. | | | A human may waive the recurrence threshold on severity. One instance plus an explicit human call is sufficient authority for a proposal, never for automatic promotion. | | | Do not create new authority, promote a proposal, mutate production, or close a claim merely because a repair was suggested. If the system has no accepted rules for failure-class identity, recurrence thresholds, evidence anchors, subsumption, or the observation window, stop at a repair proposal and name the missing contract. | | | Loop | | | 1. Collect the branch. Read the approved lesson, its evidence anchors, and its provenance. | | | 2. Confirm the leak. Find independent instances of the same failure class using the system's accepted deterministic key. Do not infer recurrence from wording alone. | | | 3. Find the owner. Read the hook, default, skill, template, or code path that currently produces the behavior. | | | 4. Shape the repair. Propose the smallest change that could prevent the failure upstream. Reuse or amend the existing owner before adding a new layer. | | | 5. Keep the human gate. Present the evidence, proposed repair, denial behavior, and proof plan for approval. Never promote automatically. | | | 6. Prove the structure. Drive the repaired surface live and test the dangerous denial case. A landed change is not yet evidence that recurrence stopped. | | | 7. Watch for silence. Observe the accepted window. Only then report that the repair holds and let the lesson be subsumed by the structure that now carries it. | | | 8. Reopen on return. If the same failure class appears after subsumption, reopen the proposal. The failed repair is now evidence. Repair v2 starts from what v1 missed, never from scratch. | | | Output | | | Return: | | | - Constraint: the repeated failure in plain language. | | | - Recurrence evidence: independent, source-linked instances. | | | - Existing owner: the narrowest surface that should absorb the lesson. | | | - Smallest repair: the bounded structural change. | | | - Dangerous denial: what must still fail closed. | | | - Human decision: approve, edit, dismiss, or request more evidence. | | | - Proof window: how recurrence will be checked after the change. | | | - Status: candidate , proposed , landed , observed , dismissed , or reopened . | | | - Retires: the memory-only path or repeated workaround this repair makes unnecessary. | | | Standard | | | Do not call a system self-improving because it stored more memory. | | | Call the repair proven only when the structure changed and the same mistake stopped recurring. |