Right tool, right job.
I started invoking my skills manually pretty early on. Partly because I was experimenting with my own and other people’s, and the agent’s auto-pick wasn’t tuned for that. The folder grew. Specialized ones started slipping out of my head. And then a wave of skills from people I respect started showing up: Jakub Krehel made his own motion skill, Emil Kowalski has one through his course, Josh Puckett shipped his interface-craft suite. Each one carries a point of view. Each one is good at a different cut of the job. For auditing a color system, I’d reach for one. For fixing a layout, a different one.
It’s the same situation I’m in when I’m making music in Ableton. I probably have fifteen different compressor plugins, and none of them sound the same. When a vocal track needs help, I want someone with the time to A/B them and tell me which one will do this particular job best. Skill Picker is the studio engineer for my skill rack. You hand it the task you’re working on. It shortlists candidates, opens each SKILL.md to verify what the workflow handles (not what the description claims), and returns a recommendation. Sometimes that’s a single skill. Sometimes it’s a chain of skills sequenced into a plan the agent can run.
When the obvious pick isn't obvious.
You’ve got a frontend job and three or four skills could do it. Two motion-design skills, both good, but tuned for different things. The animation work is in a kids app, so it’s a different fit than a productivity tool. That’s the situation Skill Picker is for. When the choice itself is part of the work.
What comes back is structured for argument. You see the rejected candidates first, each with the reason it missed. Then the better matches, with verbatim quotes pulled from the workflow body (not the one-line description). Then a primary recommendation, an optional chain to layer on top, and a tactical follow-up. After that, a handoff: invoke the primary now, generate a plan first, or stop and run things yourself.
The reasoning runs on a fixed taxonomy of five mismatch patterns. Every rejection has to map to one of them by name, which keeps the analysis from collapsing into vibes. Over-scoped description: the one-liner implies broad capability, the workflow handles a narrow slice. Outdated trigger list: the trigger keywords don’t match what the workflow branches on. Hidden prerequisite: the workflow assumes tooling, a design system, or a prior skill output the description never mentions. Output mismatch: the description promises one artifact, the workflow produces another. Audience or tone drift: the description sounds generic, the workflow is calibrated for a specific user, stack, or aesthetic.
Works in any AI coding agent
One install command, any agent. The skill rides on the open skills protocol, so it works the same in Claude Code, Codex, Cursor, OpenCode, and 35+ others. The CLI auto-detects what you have installed and wires it up.
$npx skills add kylezantos/skill-picker#Auto-detects your agent (Claude Code, Codex, Cursor, OpenCode, 35+ more)#Then run: /skill-picker [your task description]
From a habit I already had.
Original work. The skill is the version of a habit I already had: opening each SKILL.md, scanning the workflow body, deciding whether the call fit the job. The five mismatch patterns are the ones I kept catching myself. The structured output is what I’d have wanted back the first time I started picking skills by hand.