Design system
Skill eugenelim/agent-ready-repo/packs/experience-design/.apm/skills/design-system
The complete AI operating model for software teams — from first idea to production. Three peer-supervised loops (discovery → build → release) over a catalogue of curated packs: skills, subagents, and hooks, each installed in one line. It's npm for your coding agent. Any agent, any stack — Claude Code, Codex, Cursor, Copilot, Gemini, Kiro.
npx -y skills add eugenelim/agent-ready-repo --skill design-systemAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when an aesthetic direction exists and the next move is a system — deriving a token/scale taxonomy and its rationale from intent. Triggers on "derive a scale", "set up design tokens", "name our tokens", "what's our spacing/type system", "turn the direction into a system". Names tokens by semantic role, organizes scales by a single ratio-as-concept, treats accessibility as a floor, and composes atomically (build systems, not pages). Do NOT use to set the vibe first (use `creative-direction`), to lay out a screen's hierarchy and flow (use `information-architecture`), or to evaluate an existing surface (use `design-review`).
SKILL.md
3.8 KB, as published. Nobody here has run it
Skill: design-system
Produce a token/scale taxonomy and the rationale behind it, derived from a named aesthetic direction. You ship the method to derive values and a portable serialization shape — never a reprinted palette, spacing, or type table. The reader produces the numbers.
When to invoke
Before drafting, confirm:
- An aesthetic direction exists. A taxonomy without named emotional/brand
goals is arbitrary. If the direction isn't written down yet, route to
creative-directionfirst. - The ask is the system, not a screen. If the user wants hierarchy,
reading flow, or wayfinding for a specific surface, route to
information-architecture. - You're deriving, not reprinting. You will hand back the method and a taxonomy shape the reader fills with values — not a values sheet.
Procedure
- Restate the intent. Pull the named goals from the aesthetic direction. Every token decision must trace back to one of them.
- Decide purpose before token. For each thing the system needs, name what
it is for (its semantic role) before anyone picks a value. See
references/token-taxonomy-derivation.md. - Name by semantic role, not literal appearance. A token is named for the
job it does, so its value can change without a rename. Method in
references/token-taxonomy-derivation.md. - Choose one ratio as the organizing concept. Let a single ratio generate
the steps of your spacing scale and your type scale. Express steps
symbolically (step −1, base, step +1), never as numbers. Derivation in
references/token-taxonomy-derivation.md. - Set accessibility as the floor and budget contrast. Every token clears
the recognized standard (WCAG, at your context's conformance level — read
the criteria from the source). Allocate a contrast budget across the
screen rather than maxing every element. See the shared checklist at
../design-review/references/quality-floor.md. - Compose atomically. Build the system bottom-up: primitive tokens →
composed components → pages. Define once, reuse. Model in
references/atomic-composition.md. - Serialize portably. Record the taxonomy in the W3C Design Tokens
interchange shape so it travels across tools. Pointer in
references/token-taxonomy-derivation.md.
Anti-patterns to refuse
- Reprinting a values table instead of deriving one. A fixed palette, spacing scale, or type scale with numbers is the thing this pack refuses to ship. Hand back the method and a symbolic shape; the reader supplies values.
- Naming tokens by appearance. A token named for how it looks today locks the value into the name — rename hell the first time the direction shifts.
- Picking values before purpose. A number with no named role is a guess you'll relitigate. Decide what the token is for first.
- Treating accessibility as a later pass. The floor is a constraint on every token at derivation time, not a cleanup chore.
- Designing pages instead of systems. One-off screens don't compose and don't stay coherent as they grow. Build reusable elements.