The problem
Edits fix forward and break backward
Week 4 set the sharing bar: a method that works twice in a row on fresh input. That bar covers the day you ship. It says nothing about the day a teammate adds a guardrail, sharpens a step, or trims the example — and the Skill starts formatting the one report it used to handle perfectly. Nobody typed anything wrong; the edit did it, silently.
The habit
Three held-out inputs, rerun on every edit
1
Keep three test inputs beside the Skill
Pick three real, checked inputs the Skill already handles well: an ordinary one, a messy one, and the edge case that once broke it. Save them in the same place the Skill’s text lives, labeled “test inputs — do not edit.” The gate applies: nothing identifying a scholar or family, ever.2
Before the edit, capture the current outputs
Run all three once and keep the outputs. That’s your baseline: what “working” looks like today, in the Skill’s own words.3
After the edit, rerun all three
Read each new output against its baseline. You are looking for the change you intended — and any change you didn’t. The second kind is the regression.4
Log one line, then share
In the Skill’s text, keep a short changelog: date, what changed, “three checks pass.” Only then does the new version go to the team. A teammate reading that line knows the Skill was tested, and against what.The whole discipline in one sentence: a shared Skill changes only when its three held-out inputs still come back right. When a fourth kind of input starts arriving, promote one to the test set. Ten minutes per edit; the alternative is a teammate discovering the break inside a real deliverable.
Now do it to yours
Your turn, this week
Take the Skill you shipped in Week 4 (or the one your team uses most). Choose its three test inputs, run the baseline, and add the changelog line. That’s the whole exercise — the payoff arrives the first time an edit fails check three. The same shape at production scale is what the H3 walkthrough calls verification gates.