One install chains two phases: Tune-Skill audits the SKILL.md the agent actually loads — triggering description, sibling overlaps, stale names and counts, broken handoffs — and makes minimal edits validated by check_skill.py. Then Findable-Polish audits the human-facing surfaces against real queries and polishes the README, About text and site copy. The file gets fixed first because the listing is written from the final description.
install
The install line from the repo README. The chain needs tune-skill, findable-polish, findable and wordsmith; a missing dependency is named and the run stops.
npx skills add arm-pz/tune-and-polish --skill tune-and-polish
the workflow
Phase one is tune-skill's eight-step audit and edit loop, gated on the validator. Only a passing skill enters phase two, the findable-polish query audit and copy alternatives. The final report names what changed, what was polished, and what was never seen.
Read the real SKILL.md and references, check overlaps with siblings, settle boundaries, make the smallest evidenced edit.
Run the discoverability audit on README, About and site copy; write alternatives from real queries.
Changes per skill with a one-line reason, the polished copy, and an honest note on which checks ran.
A brand-new skill is draft-skill territory, or the full pipeline in skill-launch. Nothing to tune, just better listing copy? Run findable-polish alone. This chain exists for the both-at-once case.
ground rules
Every claim about a skill comes from its SKILL.md or references — READMEs and listings drift. An edit to prose that contradicts the file is the bug this order prevents.
“Looks tighter” is not a pass. Phase one ends when check_skill.py exits clean, and the report says which test cases were run versus only written.
Change what the audit found and nothing else. Honesty, safety and privacy rules never get weakened to make a description scan better.
Free, open, and every edit traces back to a quoted line or a measured query.
Install tune-and-polish Read the source