design-system
Skill4 starsChanged 8 months agoCC0-1.0View on GitHub
Collaborative design system creation using Atomic Design methodology with a structured seven-phase process (Philosophy, Tokens, Atoms, Molecules, Organisms, Templates, Assembly). Produces a specification artifact with philosophy traceability, named design tokens, and full component hierarchy. Use when creating a design system, defining a visual language, specifying UI tokens (colors, typography, spacing), building a component catalog, or planning component architecture before implementation. Triggers on: "create a design system", "define design tokens", "component library spec", "visual language", "atoms and molecules", "style guide", "UI philosophy", "component hierarchy". NOT for: implementing components in code (use atomic-design), choosing frameworks (use architecture-decisions).
We split this skill into the rules it gives an agent
13 rules. 0 are common, 9 are distinctive, and 4 are very specific to this project.
0
Common
Most of the 166 edited versions we read keep these.
9
Distinctive
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 46
Check whether the mcp__pencil__get_editor_state tool is available.
- Very specific: line 48
Present: Use .pen format. Follow references/pencil-workflow.md.
- Very specific: line 49
Absent: Use HTML format. Follow references/html-artifact.md.
- Distinctive: line 82
Do not assume visual preferences -- ask
- Distinctive: line 83
Do not skip ahead when the user gives a partial answer -- probe deeper
- Very specific: line 84
If event model wireframes exist in docs/event_model/, use them to identify required components, but still confirm with the user
- Distinctive: line 91
Every design decision traces back to the philosophy.
- Distinctive: line 99
If a token cannot cite a principle, either the token is unnecessary or the philosophy is incomplete.
- Distinctive: line 104
Use only token references in components -- never raw values
- Distinctive: line 106
Verify traceability at every level
- Distinctive: line 113
Use raw color codes, pixel values, or font names in components
- Distinctive: line 143
After completing work guided by this skill, verify:
- Distinctive: line 160
If any criterion is not met, revisit the relevant phase before proceeding.
“Common” is measured: kept by at least 6 in 10 of the 166 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Design System
Value: Communication -- a documented design system creates shared vocabulary for every visual decision. When philosophy is explicit and tokens are named, contributors extend the system consistently without guessing at intent.
Purpose
Facilitates collaborative creation of a design system specification.
Produces an artifact at docs/design-system.pen (if Pencil MCP is
available) or docs/design-system.html (single-file fallback) that
documents philosophy, tokens, and the full component hierarchy from
atoms through templates.
Practices
Detect Artifact Format
Check whether the mcp__pencil__get_editor_state tool is available.
- Present: Use
.penformat. Followreferences/pencil-workflow.md. - Absent: Use HTML format. Follow
references/html-artifact.md.
Decide the format before starting any design work. Do not switch formats mid-process.
Follow the Seven-Phase Collaborative Process
You MUST follow references/design-phases.md for the full methodology.
Each phase completes before the next begins.
Phases at a glance:
- Philosophy & Constraints -- Brand, principles, accessibility, responsive strategy, constraints. Every subsequent decision traces here.
- Design Tokens -- Color, typography, spacing, radii, elevation, motion, breakpoints, opacity. Each token cites a philosophy principle.
- Atoms -- Indivisible elements (buttons, inputs, labels, icons). Each documents states and references only tokens.
- Molecules -- Functional units composed of atoms (form fields, search bars). Documents composition and interaction.
- Organisms -- Distinct UI sections composed of molecules and atoms (headers, forms, data tables). Documents layout behavior.
- Templates -- Page layouts arranging organisms. Defines structure, content slots, and breakpoint behavior.
- Artifact Assembly -- Compile into the chosen format with philosophy as the first section.
Facilitate, Do Not Assume
You are a facilitator, not a stenographer. Ask probing questions at each
phase. Challenge choices that conflict with stated philosophy. Use
references/facilitation-questions.md for question banks.
- Do not assume visual preferences -- ask
- Do not skip ahead when the user gives a partial answer -- probe deeper
- If event model wireframes exist in
docs/event_model/, use them to identify required components, but still confirm with the user - Present token proposals informed by the philosophy and ask for adjustments
Enforce Philosophy Traceability
Every design decision traces back to the philosophy.
- Tokens cite which philosophy principle they serve (e.g.,
P1) - Atoms reference which tokens they use
- Molecules document which atoms they compose
- Organisms document which molecules and atoms they compose
- Templates document which organisms they arrange
If a token cannot cite a principle, either the token is unnecessary or the philosophy is incomplete. Resolve before proceeding.
Do:
- Define philosophy before any visual decisions
- Use only token references in components -- never raw values
- Complete each phase before starting the next
- Verify traceability at every level
- Refer to
references/token-categories.mdfor comprehensive token guidance
Do not:
- Make technology decisions (CSS framework, component library) -- those belong in architecture-decisions
- Skip the philosophy phase or treat it as optional
- Use raw color codes, pixel values, or font names in components
- Design multiple phases simultaneously
- Proceed with gaps -- if something is undefined, ask
Enforcement Note
Advisory in all modes. Phase gates are self-enforced: the agent must complete each phase's outputs and get user confirmation before proceeding. Token traceability is self-enforced: the agent must verify every component references tokens, not raw values.
Hard constraints:
- Phase ordering (complete each phase before starting the next):
[RP]
Constraints
- "No raw values in components": This means no literal color codes, pixel values, font sizes, or spacing values anywhere in component definitions. "I defined a token for it" is not sufficient if the component file contains the raw value instead of the token reference. Defining many single-use tokens to technically satisfy this rule while defeating reusability is also a violation.
- Philosophy phase: Philosophy means named principles with enough specificity to guide decisions. "Modern and clean" is not a philosophy -- it constrains nothing. Each principle should be testable: given a design decision, the principle should help you choose between options. If it doesn't eliminate any option, it's not specific enough.
Verification
After completing work guided by this skill, verify:
- Philosophy documented with named principles before any components
- Tokens defined for all visual categories (color, typography, spacing, radii, elevation, motion, breakpoints, opacity)
- Every token cites a philosophy principle
- Atoms reference only tokens (no raw values)
- Molecules compose only atoms from the catalog
- Organisms compose only molecules and atoms from the catalog
- Templates arrange only organisms from the catalog
- All component states documented (default, hover, focus, disabled, error as applicable)
- Wireframe fields mapped to components if event model exists
- Artifact exists at
docs/design-system.penordocs/design-system.html - Philosophy is the first section in the artifact
If any criterion is not met, revisit the relevant phase before proceeding.
Dependencies
This skill works standalone. For enhanced workflows, it integrates with:
- event-modeling: Wireframes from event modeling sessions identify which components the design system must include. Run event-modeling first for best results.
- architecture-decisions: The design system specification informs technology decisions for UI implementation (CSS framework, component library, build tooling). Run design-system before architecture-decisions.
- atomic-design: The design system specification provides the token definitions, component catalog, and hierarchy that atomic-design implements in code.
- tdd: Token values and component specifications become testable contracts -- visual regression tests verify token compliance.
Missing a dependency? Install with:
npx skills add jwilger/agent-skills --skill event-modelingOther versions181 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 181
- nextlevelbuilder/ui-ux-pro-max-skill★ 144ksame name
- getsentry/sentry★ 46ksame name
- anthropics/knowledge-work-plugins★ 34ksame name
- Donchitos/Claude-Code-Game-Studios★ 27ksame name
- ethereum/ethereum-org-website★ 6ksame name
- langwatch/langwatch★ 5ksame name
- joye61/pic-smaller★ 2.9ksame name
- reatom/reatom★ 1.4ksame name
- daveebbelaar/bama★ 1.1ksame name
- microsoft/power-platform-skills★ 1.1ksame name
171 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
Used alongsideProjects with it also use setup-engine, create-stories and 10 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
CoralGameSkillsetup-engine
Configure the project's game engine and version. Pins the engine in CLAUDE.md, detects knowledge gaps, and populates engine reference docs via WebSearch when the version is beyond the LLM's training data.
Also in 13 projects that use this
lilangMaxSkillcreate-stories
Break a single epic into implementable story files. Reads the epic, its GDD, governing ADRs, and control manifest. Each story embeds its GDD requirement TR-ID, ADR guidance, acceptance criteria, story type, and test evidence path. Run after /create-epics for each epic.
Also in 11 projects that use this
lilangMaxSkillstory-done
End-of-story completion review. Reads the story file, verifies each acceptance criterion against the implementation, checks for GDD/ADR deviations, prompts code review, updates story status to Complete, and surfaces the next ready story from the sprint.
Also in 11 projects that use this
CoralGameSkillteam-level
Orchestrate level design team: level-designer + narrative-director + world-builder + art-director + systems-designer + qa-tester for complete area/level creation.
Also in 12 projects that use this
- +2 more from CoralGame
- +6 more from lilangMax
In this repository21 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- bumpSkill
- agent-coordinationSkill
- architecture-decisionsSkill
- atomic-designSkill
- bootstrapSkill
- ci-integrationSkill
- code-reviewSkill
- debugging-protocolSkill
- domain-modelingSkill
- ensemble-teamSkill
- event-modelingSkill
- factory-reviewSkill
- memory-protocolSkill
- mutation-testingSkill
- pipelineSkill
- session-reflectionSkill
- task-managementSkill
- tddSkill
- ticket-triageSkill
- user-input-protocolSkill
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
Reviews can't be read right now.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

