A starred repo isn't a skill. It's a bookmark you'll forget.

I used to treat a starred repo like a decision already made, as if clicking the star had done the work of adopting the skill. It hadn't. The repo sat in a list I revisited maybe twice a year, usually to add one more star to it. A skill you never installed is worth exactly what a skill you never found is worth: nothing. The list itself started to feel like progress, and that's the trap - collecting is easy to mistake for curating, because both produce a longer list.

That's not an argument against keeping a list in the first place - a good one is still a fine place to start. The twenty-four below are real, working repos, not vaporware. The problem is never the list itself. It's stopping at it.

Installing a skill doesn't prove anything either - it just moves the question from "does this exist" to "does this help", and the second question is one you can actually answer. Point a newly installed skill at real work: a real code review, a real design pass, a research question you already needed answered. Then read the result the way you'd read a colleague's first draft - not whether it's impressive, but whether it changed the actual outcome or just the vocabulary around it.

This is also where the flags above earn their keep: --list before you commit to anything, --skill <name> when a repo bundles more than you need, -g once something has proven itself enough that you want it everywhere.

Delete a skill the moment it stops changing your output and starts running purely out of habit. That's a different failure than a skill that never worked - this one worked once, earned its install, and then quietly became overhead. The tell is usually the same: you notice it sitting in a list of installed things and can't remember the last time it actually mattered.

A shelf of twenty-four installed-but-idle skills isn't meaningfully better than a shelf of twenty-four starred-but-never-installed ones. The size of either list was never the point.