design-system-boss

design-system-boss is the entry skill. You say what is wrong in plain words, such as "our UI is a mess, fix it", and it reads the app, picks one playbook and runs the other design.how skills in order, ending with one report.

When to use it

Use for vague whole-app design system asks on an app that already ships UI, such as "our UI is a mess, fix it", "we need a design system", "we hardcode colors everywhere", "make the buttons consistent" or "check the app before I ship". One named screen goes to ui-review, one component to component-docs, a token report to token-mapping. A repo with no UI yet is out of scope.

What it does

  1. Reads the app and matches the ask to one playbook: review a named screen, document one component, build a system, or migrate onto one.
  2. Copies that playbook's steps into .design-system/state.md word for word. A step it drops stays in the list as skipped, with the reason.
  3. Asks every question once, with its default already applied (taste, design source, pilot flow), and keeps going.
  4. Writes the roles for the run (coordinator, worker, verifier, reviewer) so the agent that wrote something never grades it.
  5. Runs the playbook. An installed design system is the source of truth, so no playbook builds over it.

What you get back

A final message that opens with the questions nobody answered and the defaults it took, then what changed, then one ranked table of what it found and did not fix, 30 rows at most. Every number comes from a command run at the end.

What it never does

  • Push or deploy without being asked, or commit on the branch the run started on.
  • Start a migration on a vague "fix it".
  • Choose a visual direction nobody chose. "Make it modern" with no source keeps the current look.

Install

design-system-boss installs with the other five design.how skills, for Claude Code, Cursor, Codex and any agent that reads Agent Skills. The install command and the .zip are on Skills, free after an email signup.

The other skills

  • build-design-system: Builds a design system from the UI your app already ships: tokens, components, docs and checks, proved on one flow.
  • migrate-design-system: Moves every screen of an app onto an existing design system with many agents, each screen checked against its before screenshot.
  • token-mapping: Reports how the hardcoded colors and sizes in your code map onto your design tokens, by purpose. It never edits.
  • ui-review: Reviews a screen, flow or running build, accessibility included, and ranks what is broken with evidence.
  • component-docs: Writes one component's documentation from its code and two real uses, with rules next to the examples.