Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/vmobifystudio/app-dev-team/design-systemnpx skills add vmobifystudio/app-dev-team --skill design-systemgit clone --depth 1 https://github.com/vmobifystudio/app-dev-teamWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/vmobifystudio/app-dev-team/design-system)<a href="https://agentmods.dev/skills/vmobifystudio/app-dev-team/design-system"><img src="https://agentmods.dev/badge/skills/vmobifystudio/app-dev-team/design-system.svg" alt="Measured on agentmods" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00072 | $0.00579 |
| Opus 5 | $0.00036 | $0.00290 |
| Sonnet 5 | $0.00014 | $0.00116 |
| Haiku 4.5 | $0.00007 | $0.00058 |
Grade A, and why
design-system scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured today.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 46 lines — stays where its author put it; the contents beside it link to each section on GitHub.
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
- Primitive — the raw values.
blue-600 #2563EB,space-4 16,dur-fast 150ms. No screen ever references a primitive directly. - Semantic — what it means.
text/primary,surface/elevated,semantic/error,motion/enter. Screens reference these and only these. - 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.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- today First seen · 46 lines · 72 tokens per session scan A f5bd945b638c
design-system is a skill published in the GitHub repository vmobifystudio/app-dev-team (4 stars, last pushed 24d ago), licensed MIT. It adds 72 tokens to every session and 579 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-09-03.
Other skills, from other repositories
prd
Generates a Product Requirements Document from a natural language app description. Asks clarifying questions, researches similar apps, defines scope, stack, architecture, and produces a structured PRD that Archon can decompose into a campaign.
deslop
The optimization pass, defined - delete before you add, one smell class per pass, behaviour pinned by a test that ran BEFORE the edit. Lints a SKILL.md and prose by the same instinct. Use for the per-story optimization pass or when code has grown noisy without growing capable.
execute-task
Implement one task (or a cohesion bundle) from a signed-off spec (Ready or Active): recompute the execution freshness gate, write the verifying test first, implement to green, run the project's full CI with adaptive retry, converge via the configured reviewsequence (default /polish --nested), then open a draft PR…
builder
Detect a project's stack and recommend or apply the universal mechanical quality guards from planwright's core catalog (formatter, linters, type-checker, test runner, secret scan, commit hooks, CI gate), plus the growable breadth dimensions. Escalates stake-bearing decisions (auth, data modeling, security posture…
spec-walkthrough
Render a spec bundle (or a chosen slice) into a plain-language, didactic comprehension artifact a human reads and judges for themselves: an unaided cold read before kickoff, re-orientation mid-execution, or onboarding to a finished or abandoned spec. Standalone and strictly read-only: it renders any status, never…
drain
Run the on-demand drain pass over every spec bundle's Gate deferral entries: evaluate structured GATE(when:) conditions, surface date and free-text gates, report malformed ones, inventory each live bundle's [manual] test-spec entries, and surface the observations log's unmined state. Read-only; nothing is…