UX-OS

UX skills for Claude, run like an operating system.

Free written methods for Claude Code, in eleven sets. One record of what loads, who wrote it and what testing showed.

A pile of skills is not a system.

On 24 October I built an information-architecture skill, because two public ones shared a name and couldn't be installed together. Then I tested it against no skill at all. With the skill: 24 out of 25. Without it: 23.

One point. Installing a skill told me nothing about whether it helped, or whether Claude would ever open it. An operating system answers those questions for programs: what's loaded, who gets priority, what each one costs. UX-OS answers them for skills. There's no package to install. It's four jobs you do on whatever you've got, and the record of how they came out.

  1. 36 of 505

    Roughly, in one project of mine: skills that get a description in Claude's list

    Decide what loads.

    With that many installed, the rest show up as a bare name, so a better description changes nothing. So each entry gets a decision, made in Claude Code's own settings: load it, keep it for when I call it by name, or switch it off. The marks above are those decisions. To see yours, ask a fresh session to quote its skill list.

  2. 9 of 10

    requests chosen under its real name. Under a temporary test name: 0 of 10

    Settle who wins.

    Two skills can claim the same job. With a temporary test name, mine won none of ten requests and a rival took nine. Under its real name, Claude chose it nine times out of ten, and on none of ten near-misses. The name is the interface.

  3. 28 vs 19

    of 29 checks in the latest round, with the skill and without

    Make each skill earn its place.

    After that first round I fixed what failed and sharpened the checks. The gap has held for two rounds since, and every grade is public.

  4. +49%

    longer runs in the latest round, and about 19% more tokens

    Put the cost beside the score.

    Better answers aren't free. When the number's written down, you get to decide when it's worth paying.

One skill, three test cases, and I wrote both the skill and the checks. That's a field note, not a study.

The case against all this: skills are cheap, so install everything and let Claude sort it out. Fair. That's how I got to 505. Then I asked Claude to show me what it could actually see.

Most of this is other people's work.

29 of the 37 entries are third-party, and MC Dean wrote 23 of them. I built seven and rewrote one from public sources. What I'm adding is the filing, the testing and the decisions about what stays on.

One command adds the marketplace behind 23 of the 37.

/plugin marketplace add Owl-Listener/designer-skills

That makes the packs installable. Deciding which ones stay on is the system. Each set page has the install commands.

Eight steps. So far, one skill has had the full test.

Seven sets have nothing I built. Three are still proposals. Most of the registry has never been tested against anything. This is the method for anything new.

  1. Check what already exists

    Search the registry and the installed skills first.

  2. Decide how to get it

    Adopt one, combine several, or write it.

  3. Check the licence

    No open licence means rewrite, never copy.

  4. Write the skill and its tests together

    Method, reference material and realistic cases.

  5. Test it against no skill at all

    Run each case both ways. Record score and cost.

  6. Test the real name

    Most skills reach Claude by name alone.

  7. Check Claude can reach it

    Nothing hides it, and nothing shares its name.

  8. Register it

    One row, with how it was built.

Read the whole method

Pick one discipline. Test it against nothing.

Install one set. Run your next real task with it and without it. If you get 24 to 23, you'll want to know.

Pick a discipline