Close the gap between a correction and it happening again.
Scans a session for corrections, approvals, and validated patterns, then proposes exact edits to your skills and docs. Nothing applied until you approve.
Inside: The session scan, high vs medium confidence, and a per-edit approval gate.
Install it in one line, or paste it in.
~/.claude/skills/ and runs automatically when it is relevant.Connect your context. Set it to your motion.
it finds the actual skill or doc file the update belongs in and drafts the diff.
it can point proposed edits at the living playbook, not a copy.
it links each accepted change to the decision that justified it.
This was built for an operator whose skills and playbooks are living documents. Set these to your setup:
The confidence split is the safeguard. Tune what clears each bar. The rule that nothing applies without approval does not move.
| Set this | What it is | Default / Example |
|---|---|---|
| TARGETS | what can be updated | your skillsplaybooksSOPsdocs |
| CODE_HOME | where skills/docs live | a git repoa docs folder |
| NOTES_HOME | where playbooks live | a notes/wiki tool |
| HIGH_BAR | what counts as high-confidence | an explicit correction you made |
| MED_BAR | what counts as a pattern | a behavior that repeatedunconfirmed |
| AUTO_APPLY | whether anything applies without asking | offalways off |
Everything the skill does, in full.
Reads back over a session and turns feedback into durable improvement. It finds where you corrected the work, where you approved it, and where a pattern proved itself more than once, then proposes exact edits to the skills, playbooks, or docs that produced the work. A correction you make twice is a rule you never wrote down. This writes it down, and shows it to you before anything changes.
- 1Session scan
Walk the session for three signals: corrections (you told it to do something differently), approvals (you confirmed something was right), and patterns (the same choice held up more than once). Everything downstream is anchored to a real moment in the session, quoted, not inferred.
- 2High-confidence corrections
An explicit correction is high-confidence. You said "no, do it this way." That becomes a proposed edit stated plainly, with the before, the after, and the exact spot it changes. These are the sure things, and they are listed first.
- 3Medium-confidence patterns
A pattern that repeated but was never confirmed is medium-confidence. It is proposed as a question, "you did X twice, should this be the default?", not asserted as a rule. Medium items never get promoted to high on their own.
- 4Proposed edits, file by file
Each accepted signal maps to one target and one concrete change. It shows what the doc says now and what it would say. If a repo is connected, it drafts the diff. If not, it hands you the exact text to paste.
- 5The approval gate
Nothing is written. Every proposed edit is presented for a yes or no, one at a time. You can accept the corrections and defer the patterns, or the reverse. The loop closes only on what you approve.
- Nothing is written, committed, or deleted without your explicit approval, per edit. AUTO_APPLY is off and stays off.
- Every proposed update quotes the moment in the session that justifies it. No update without evidence.
- High-confidence and medium-confidence are never blended. A guess is labelled a guess.
- A pattern is never silently promoted to a rule. It stays a question until you answer it.
CLOSED LOOP · onboarding-automation session · 3 signals found
HIGH CONFIDENCE (explicit corrections)
1. You corrected: "route by company size, not persona."
Target: the routing playbook, step 2.
Now: "Assign owner by persona match."
To: "Assign owner by company size band."
[ ] Apply [ ] Skip
MEDIUM CONFIDENCE (patterns, unconfirmed)
2. You batched the job nightly twice this week without being asked.
Should "nightly, not real-time" become the default in the SOP?
[ ] Make it a rule [ ] Leave as a one-off [ ] Ask me later
DO THIS FIRST
Apply #1. It is an explicit correction and it changes live routing.
(nothing above is written until you choose)
Where an operator takes this next.
Reviewing one session by hand catches what you just corrected. Here's how the habit compounds.
A correction made once is feedback. A correction captured every time is a system that stops repeating its own mistakes.
Wire a scheduled Claude task to scan the day's sessions each evening and queue proposed edits for a morning approval pass, so nothing gets lost between sessions.
Connect a git repo so accepted corrections land as real pull requests against your skills and playbooks, not just text you have to paste in yourself.
Log every approved edit to a Notion or wiki changelog so the team can see which corrections became permanent rules and when.
One skill is the on-ramp.
A single skill does one job. Chained into a playbook, or run as a full build, it becomes a system. Here is where this one plugs in.