accessibility-gate
Use as a pass/fail gate on any diff with a user-facing surface — by code-reviewer during review, by qa-engineer during the test…
@vmobifystudioInstall SkillDevelopment
Skill
/design-system
Use when defining or extending design tokens and the shared component library — by product-designer when writing docs/13-design-tokens.md and docs/14-components.md, and by any IC about to add a component. Triggers the moment a value would be hardcoded instead of named, or a
Claude Code
$ npx -y skills add vmobifystudio/app-dev-team --skill design-system --agent claude-code
Codex
$ npx skills add vmobifystudio/app-dev-team --skill design-system -a codex -y
Cursor
$ npx skills add vmobifystudio/app-dev-team --skill design-system -a cursor -y
Gemini CLI
$ npx skills add vmobifystudio/app-dev-team --skill design-system -a gemini-cli -y
GitHub Copilot
$ npx skills add vmobifystudio/app-dev-team --skill design-system -a github-copilot -y
OpenCode
$ npx skills add vmobifystudio/app-dev-team --skill design-system -a opencode -y
Windsurf
$ npx skills add vmobifystudio/app-dev-team --skill design-system -a windsurf -y
SKILL.md
design-system.SKILL.mdname: design-system
description: Use when defining or extending design tokens and the shared component library — by product-designer when writing docs/13-design-tokens.md and docs/14-components.md, and by any IC about to add a component. Triggers the moment a value would be hardcoded instead of named, or a one-off component would be created instead of composed.
Design system
A design system is not a document, it is a **constraint that holds at build time**. Tokens nobody is forced to use are a colour list.
Three layers, in this order
1. **Primitive** — the raw values. `blue-600 #2563EB`, `space-4 16`, `dur-fast 150ms`. No screen ever references a primitive directly. 2. **Semantic** — what it means. `text/primary`, `surface/elevated`, `semantic/error`, `motion/enter`. Screens reference these and only these. 3. **Component** — what a component uses. `button/primary/background` → `semantic/action`.
Skipping layer 2 is the failure: a dark mode, a rebrand or a contrast fix then edits every screen.
The rules
- **A hardcoded colour, spacing, radius, duration or font size in a screen is a defect**, not a
style preference. Name it or use the token that already exists.
- **Every semantic token names its dark-mode value at the same time.** A token added light-only is a
dark-mode bug already merged.
- **A new component needs a reason the existing ones cannot compose it.** Write the reason in
`docs/14-components.md`. "It looked different in the mock" is not one.
- **Every component declares its states** — default, pressed, disabled, loading, error, empty where
applicable — and its minimum touch target (44pt iOS / 48dp Android).
- **Contrast is checked when the token is defined**, not when accessibility is audited. Text pairs
meet 4.5:1, large text and non-text 3:1. A token failing contrast never ships and is never "fixed downstream".
Extending versus forking
Before adding anything, in this order: use the existing component → extend it with a prop → compose two existing ones → add a new one. Stop at the first that works. The third is where most teams stop too early and the fourth is where design systems die.
Output
Tokens go in `docs/13-design-tokens.md`, components in `docs/14-components.md`. Both are single-owner files — `product-designer` writes them, everyone reads them. An IC that needs a change asks; it does not edit.
Read more
name: design-system description: Use when defining or extending design tokens and the shared component library — by product-designer when writing docs/13-design-tokens.md and docs/14-components.md, and by any IC about to add a component. Triggers the moment a value would be hardcoded instead of named, or a one-off component would be created instead of composed.
Design system
A design system is not a document, it is a **constraint that holds at build time**. Tokens nobody is forced to use are a colour list.
Three layers, in this order
1. **Primitive** — the raw values. `blue-600 #2563EB`, `space-4 16`, `dur-fast 150ms`. No screen ever references a primitive directly. 2. **Semantic** — what it means. `text/primary`, `surface/elevated`, `semantic/error`, `motion/enter`. Screens reference these and only these. 3. **Component** — what a component uses. `button/primary/background` → `semantic/action`.
Skipping layer 2 is the failure: a dark mode, a rebrand or a contrast fix then edits every screen.
The rules
- **A hardcoded colour, spacing, radius, duration or font size in a screen is a defect**, not a
style preference. Name it or use the token that already exists.
- **Every semantic token names its dark-mode value at the same time.** A token added light-only is a
dark-mode bug already merged.
- **A new component needs a reason the existing ones cannot compose it.** Write the reason in
`docs/14-components.md`. "It looked different in the mock" is not one.
- **Every component declares its states** — default, pressed, disabled, loading, error, empty where
applicable — and its minimum touch target (44pt iOS / 48dp Android).
- **Contrast is checked when the token is defined**, not when accessibility is audited. Text pairs
meet 4.5:1, large text and non-text 3:1. A token failing contrast never ships and is never "fixed downstream".
Extending versus forking
Before adding anything, in this order: use the existing component → extend it with a prop → compose two existing ones → add a new one. Stop at the first that works. The third is where most teams stop too early and the fourth is where design systems die.
Output
Tokens go in `docs/13-design-tokens.md`, components in `docs/14-components.md`. Both are single-owner files — `product-designer` writes them, everyone reads them. An IC that needs a change asks; it does not edit.
Ships withapp-dev-team
Describe your app idea in one line. Get a shipped iOS & Android app. AI App Studio is a team of 30 AI specialists — a CEO, product manager, designers, iOS/Android engineers, a code reviewer, QA, and a release manager — that works like a real software studio.
532 skills30 agents
Stars on GitHub
Momentum
- stars in total
- 5
Other skills on app-dev-team.
@vmobifystudioInstall Skillagent-isolation
Use before spawning any agent that writes files, and by every developer/fixer agent as its first and last action. Gives each…
@vmobifystudioInstall Skillarchitecture-builder
Use to produce the technical architecture doc and engineering principles for a mobile app. Used primarily by the CTO agent.…
@vmobifystudioInstall Skillboard-doctor
Use to validate docs/31-board.md before spawning any agent, and to verify a developer's "DONE" claim before moving a row to…
@vmobifystudioInstall Skillbrownfield-onboarding
Use when pointing the team at an EXISTING, already-built app instead of a blank project — detects the stack, reverse-engineers…
@vmobifystudioInstall Skillbusiness-model
Use when deciding or revisiting how the product makes money — pricing, tiers, trial shape, ad load, unit economics — by ceo when…
@vmobifystudioInstall SkillMore skills from other plugins.
Auto-invoked
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
@obraInstall Skillask-matt
Ask which skill or flow fits your situation. A router over the skills in this repo.
@mattpocockInstall SkillAuto-invoked
Questions about design-system.
- Which coding agents can use design-system?
- design-system installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.