7.3
Install, Test, Amend
Why this exists
You've got three skills you'd be willing to run. Now you run one — and immediately change it, because the version someone else wrote was written for their work, not yours.
The habit this builds is small and it separates people who get value from skills from people who collect them.
The idea
Never run a skill off the shelf on anything that matters. Install, test on rubbish, then make it yours.
Three steps, and the middle one is the one people skip.
Install. Straightforward — Claude can clone or copy it into place. Confirm afterwards that it's actually available, because "installed" and "available" aren't always the same thing.
Test on something disposable. Same principle as your sandbox folder in 1.3, for the same reason. You're finding out what the skill actually does, which is not necessarily what reading it suggested. Reading tells you intent. Running tells you behaviour.
What to watch for on the test run:
| Watch | Because |
|---|---|
| Did it fire at all? | If not, it's the description — 7.1 |
| Did it do what you expected? | Reading and running often differ |
| Did it touch anything unexpected? | git diff, same as 5.3 |
| Is the output actually useful? | Working and useful aren't the same |
Amend. This is the step that turns a downloaded file into something worth having. Someone else's skill encodes their standards, their formats, their tools. Yours are different.
The usual changes are small: tighten the description so it fires when you want it, change the output format to match how you work, remove a step you don't need, add the constraint you always end up adding by hand.
A skill that's 80% right and unedited is worse than no skill, because it produces confidently wrong-shaped output that you then fix by hand every time — and you'll keep doing that rather than spending five minutes fixing the source.
One practical note: keep your amended version separate from wherever it came from. If you edit in place and the source updates, you either lose your changes or you're stuck. Copy it, rename it, make it yours.
Do
- Install one of the three skills you kept in 7.2.
- Confirm it's available — ask Claude to list your skills and check it's there.
- Run it in your sandbox on throwaway material.
- Note: did it fire on its own, or did you have to name it? If you had to name it, the description is weak.
- Run
git diff— did it touch anything beyond what you expected? - Judge the output honestly. Is it useful, or just not-broken?
- Make at least two changes: tighten the description so it fires reliably, and change one thing about the output to match how you work.
- Copy your amended version somewhere of your own, separate from the source.
- Run it again on the same input. Compare before and after.
- Write
amended.md: what it did originally · what you changed · why · what it does now.
Step 4 is diagnostic. A skill you have to invoke by name every time isn't working as a skill — it's a document you're reading aloud.
Done when
Never do
Never run a downloaded skill against work that matters on its first outing. Sandbox first. Reading tells you intent; only running tells you behaviour.
Never leave a skill at 80%. You'll pay the missing 20% by hand every time you use it, and you'll never go back and fix the source.