mobile-design-system
Skill3 starsChanged 3 months agoMITView on GitHub
Extract, define, and govern reusable mobile design tokens, foundations, components, themes, accessibility semantics, and platform variants from Design DNA, UI specifications, or an existing app. Use when Codex needs a standalone mobile design system instead of product-specific screen styling, or when a UI package must become a maintainable implementation library.
3 other projects use a version of this.
Adopted by
Most recently taken up by
- JuanMarchetto/agent-skillstheir own version, first seen Nov 8, 2026
- draftbit/mobile-taste-skilltheir own version, first seen Nov 1, 2026
- rikucherry1993/mobile-design-system-skilltheir own version, first seen Oct 13, 2026
Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 3
- draftbit/mobile-taste-skill★ 9same name
- JuanMarchetto/agent-skills★ 5same name
- rikucherry1993/mobile-design-system-skill★ 4same name
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.
In this repository11 other files it gives its agents.
- analyze-mobile-uiSkill
- mobile-design-osSkill
- mobile-design-reviewSkill
- mobile-design-to-codeSkill
- mobile-platform-guidelinesSkill
- mobile-product-briefSkill
- mobile-prototypeSkill
- mobile-reference-researchSkill
- mobile-ui-designSkill
- mobile-ux-architectSkill
- mobile-wireframeSkill
The file
We split this skill into the rules it gives an agent
4 rules. 0 are common, 2 are distinctive, and 2 are very specific to this project.
0
Common
Most of the 3 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 24
Read references/system-rules.md for token and component boundaries.
- Very specific: line 33
Run python3 scripts/validate_design_system.py <path-to-design-system.json> and fix every error.
- Very specific: line 35
If ui-design.json contains visualExploration, run the validator with --source-ui and reject any Design System whose visualLock is missing, …
- Distinctive: line 45
Do not finish with a color palette alone, a component gallery with no state semantics, or a system that cannot explain how a new screen …
“Common” is measured: kept by at least 6 in 10 of the 3 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
Mobile Design System
Turn visual intent and repeated UI behavior into a small, semantic, accessible system that can survive new screens and platform variants.
Establish the input contract
Prefer design-dna.json, ui-design.json, and the selected visual-direction.md. For new or replacement visual work, require the ui-design.json visual lock and consume its selected style family, reference IDs, theme variant, and exact theme tokens. Preserve provenance: inherited values come from an upstream artifact, specified values are deliberate target decisions, and estimated values remain estimates. Never turn a screenshot guess into an observed token.
Build the system in layers
- Define foundations: color roles, type roles, spacing, shape, elevation/material, iconography, motion, content voice, and accessibility rules.
- Copy the locked reference fingerprint into the system thesis and keep the selected semantic theme tokens as the renderer source of truth.
- Define tokens as
primitive → semantic → componentwhere the system benefits from the extra layer. Prefer semantic roles over raw values in screen contracts. - Define components by user meaning and repeated anatomy, not by a generic “card” bucket.
- Specify default, pressed, focused, selected, disabled, loading, success, warning, failure, stale, expired, and permission states as applicable.
- Record light/dark, compact/regular, iOS/Android, large-text, keyboard, Reduce Motion, and localization variants.
- Establish governance: naming, deprecation, change ownership, contrast/target-size checks, and acceptance signals.
Read references/system-rules.md for token and component boundaries. Use references/design-system-schema.md before creating structured output.
Produce and validate
Create:
design-system.mdusing assets/design-system-template.md.design-system.jsonusing assets/design-system-template.json.
Run python3 scripts/validate_design_system.py <path-to-design-system.json> and fix every error. When a UI artifact is available, also validate that every referenced UI token and component has a system definition.
If ui-design.json contains visualExploration, run the validator with --source-ui and reject any Design System whose visualLock is missing, unlocked, or inconsistent with the chosen direction. Never rebuild the system from Design DNA alone after a visual lock exists.
Enforce the output order
- System thesis, scope, and provenance.
- Foundations and semantic tokens.
- Component contracts and state behavior.
- Themes, platform variants, and accessibility pressure.
- Governance, coverage, open questions, and confidence.
Do not finish with a color palette alone, a component gallery with no state semantics, or a system that cannot explain how a new screen consumes its roles.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
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.