Turn feedback and outcomes into proposed skill fixes you approve.
Reads QA findings, feedback, and outcomes, then proposes concrete changes to your skills and scoring. You approve, nothing self-edits.
Inside: The feedback streams, the four change types, and an approval gate on every merge.
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 reads reactions, click-through, and re-asks automatically instead of you summarizing them.
cross-references what a skill predicted against what actually happened (did the AT_RISK deals slip, did the high-fit accounts convert).
writes each proposed change as a reviewable diff you can approve in one click.
This was built to evolve a suite of GTM skills. Set these to your stack:
| Set this | What it is | Default / Example |
|---|---|---|
| FEEDBACK SOURCES | where signal comes from | thumbs up/downreactionsclick-throughwritten notes |
| OUTCOME SOURCE | how you attribute results | CRM outcomeswin/lossrenewal result |
| SKILL LIBRARY | what it proposes changes to | your SKILL.md filesscoring rubricsworkflow specs |
| APPROVAL GATE | who signs off | youalways; nothing auto-merges |
| RETIRE_DAYS | unused window before a deprecation proposal | 90 |
| ACCURACY_FLOOR | precision below which a skill gets flagged | 75% |
Everything the skill does, in full.
Turns the signals your system is already producing (quality-check findings, feedback reactions, and real outcomes) into a short list of concrete proposed changes to your own skills, scores, and workflows. Each one arrives as a reviewable proposal with the data behind it. You approve; the system updates. It never edits itself. This is the layer that makes a library of skills improve over time instead of drifting.
- 1Read both feedback streams
Implicit signals (reactions, click-through, re-asks, outcome attribution) and explicit signals (thumbs plus structured reasons). Neither alone is enough. A single thumbs-down is noise; the same pattern across both streams is a signal worth acting on.
- 2Attribute outcomes honestly
Cross-reference each skill's predictions to what actually happened, controlling for cohort confounds (window size, segment mix, sample size). Never claim a lift without accounting for what else moved. Small samples lie, and a self-improving system that believes its own inflated numbers gets worse, not better.
- 3Propose, never merge
Every change ships as a reviewable proposal with a diff and a rationale tied to data. Four kinds:
- Tighten a rubric: when two tiers converge on the same outcome, collapse or re-cut them.
- Update a trigger or definition: when language in the field has shifted (a new tool named in calls, a new phrase reps use).
- Propose a new workflow: when the same sequence of skills fires together often enough to bundle.
- Retire a skill: when it is unused past RETIRE_DAYS or persistently below ACCURACY_FLOOR.
- 4Name the one thing to review first
Every pass ends by surfacing the single highest-priority change, usually the skill whose accuracy dropped below the floor, with the specific cases to investigate.
- Every proposal has a rationale tied to data. Not "tighten this rubric" but "STRONG_FIT converted at 82% and FIT at 79%, too close to differentiate. Collapse to one tier plus an above-baseline override."
- Nothing auto-merges. Every change is a reviewable proposal you approve before anything updates.
- Outcome claims are honest. No "we improved win rate by 5%" without controlling for cohort confounds.
- A skill is retired only on evidence: low invocation past the window, or precision below the floor, never a hunch.
EVOLUTION PASS - week of May 25 4 proposed changes ready for review 1. Tighten the fit rubric STRONG_FIT converted 82%, FIT 79% (too close). Collapse to one tier plus an "above-baseline" override. 2. Add a term to the tech-stack list A tool showed up in 12 calls this month vs 4 last quarter. 3. Propose a new workflow: renewal prep The same 3 skills fired in the same order 17 times. Bundle them. 4. Retire an unused skill Invoked twice in 180 days, both tests. Deprecate. Accuracy (trailing 90 days): Fit scoring 82% Deal health 78% Churn predict 67% <- below the 75% floor Review first: churn prediction at 67%. Tighten it or lower its confidence.
RETIRE_DAYS (90), the 75% accuracy floor, and the trailing-90-day window are defaults from one team's cadence, not laws. A fast-moving library wants a shorter unused window; a high-stakes one wants a higher accuracy floor. Re-tune them to how much risk you carry. The loop (read both streams, attribute honestly, propose, approve) does not change. The thresholds are yours.
Where an operator takes this next.
The manual pass proves the loop works. Here is what it looks like running continuously.
You still approve every merge. The pass just stops depending on someone remembering to run it.
Put this on a monthly scheduled Claude task so drift gets caught before a quarter goes by, not after.
Connect Slack reactions and Amplitude click-through so implicit and explicit feedback both flow in without anyone logging them by hand.
Wire a GitHub connection so each proposed change lands as a pull request against the SKILL.md, ready for one-click review instead of a paragraph to re-type.
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.