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 skills add jxoesneon/Ciel --skill design-system-skillgit clone --depth 1 https://github.com/jxoesneon/CielWrote 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/jxoesneon/ciel/design-system-skill)<a href="https://agentmods.dev/skills/jxoesneon/ciel/design-system-skill"><img src="https://agentmods.dev/badge/skills/jxoesneon/ciel/design-system-skill/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/jxoesneon/ciel/design-system-skill"><img src="https://agentmods.dev/badge/skills/jxoesneon/ciel/design-system-skill.svg" alt="Reviewed on agentmods" width="80" 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.1 | $0.00075 | $0.02525 |
| Opus 5.5 | $0.00030 | $0.01010 |
| Sonnet 5.5 | $0.00015 | $0.00505 |
| Haiku 4.5 | $0.00007 | $0.00252 |
Grade A, and why
design-system-skill 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 27d ago.
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.
Copies of this mod
1 near-identical copy found in the catalogue:
- design-system — 100% identical, 11 lines differ
How it starts
The opening of the file, as written. The whole thing — 102 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Building on a Design System (frontend code)
A way to build UI in a frontend codebase on top of an existing design system. You discover the system, record what you find in a per-project reference, reuse its components, and bind to its tokens — accreting knowledge as you go. The skill holds the method; the per-project reference holds the system.
Rules
- Read-only by default. Treat the codebase as read-only until the user points you at where to write.
- Confirm before writing. Name what you're about to change and get a clear go-ahead. Don't infer permission from intent.
- Verify the system before building; never invent it. Confirm the resolved design-system source with the user, and surface what you can and can't reproduce from it, before generating UI. If the system is ambiguous or incomplete, or a token / component / icon can't be sourced from it, ask — do not silently substitute an invented token, a look-alike component, or a hand-drawn icon and present it as on-system. Fabricated fidelity is worse than a flagged gap.
How to operate
- Find the design system — and confirm the source before building. The system's source may be (a) the codebase — dependencies (a UI package like MUI / Chakra / shadcn / Radix, or an internal
@org/ui), a local components directory, and the token source (Tailwind config, CSS custom properties, a tokens file/DTCG, a theme object) — or (b) a Figma reference the user provides (a library/file URL), when the real system lives in Figma rather than in code (e.g. a native app with no web component library). Detect (a) by inspecting the codebase; take path (b) whenever a Figma reference is passed (see "Figma-sourced design systems" below). If neither is present, surface what's installed or available and offer those as options, or ask which to adopt — don't invent one. Then confirm the resolved source — and what you can/can't reproduce from it — with the user before building (Rule 3). Also confirm what you're building and where it's allowed to write. - Discover foundations by introspection (see the Foundations checklist below) — read the types, the theme/token source, and any Storybook/docs — and record them by copying
design-system-reference.template.mdinto the project (or a section ofCLAUDE.md). - Discover components on use. The first time you reach for a component, introspect its props — its TypeScript types, Storybook args, or source. Record the selection axes + key props + any non-introspectable gotcha.
- Build on the framework. Reuse the app shell / layouts / page or route templates the system or app already defines, rather than recomposing chrome from primitives. If undocumented, inspect or ask where new UI belongs.
- Capture as you go. Add confirmed patterns and gotchas to the reference so the next session doesn't re-learn them.
What ships with it
1 file beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
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.
- 27d ago First seen · 102 lines · 75 tokens per session scan A a0138afb9875
design-system-skill is a skill published in the GitHub repository jxoesneon/Ciel (1 stars, last pushed 4d ago), licensed Apache-2.0. It adds 75 tokens to every session and 2,525 once invoked, about $0.0003 per session on Opus 5.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-24.
Other skills, from other repositories
hatch3r-design-system-detect
Detects existing design tokens, component library, and theming convention in a project before authoring new UI primitives — output a concise inventory for downstream implementers.
design-md
Pick a design language from a categorized offline catalog of 152 entries (84 brand-inspired DESIGN.md files and 68 generic styles), write it as DESIGN.md in the project root, then implement or restyle production UI from that file and verify it in a running page. Use when the user asks to list or compare design styles…
Design System Component Reuse Guard
A code review check that spots new buttons, inputs, modals, cards, and similar interface pieces built from scratch when reusable design-system components already exist. It also suggests importing the existing component.
Design Token Enforcement
A code review check that finds hard-coded colors, spacing, font sizes, rounded corners, and shadows in frontend code when the project already provides design tokens. Design tokens are named shared values, such as a primary color or medium spacing.
design-system-generator
Generate a complete, production-ready design system from a single brand color. Outputs OKLCH color palettes, W3C Design Tokens (JSON), CSS custom properties, component styles (Button, Card, Input, Badge, Alert, Modal, etc.), and a live preview HTML page with Light/Dark theme toggle. Trigger this skill when the user…
web-ui-polish
Transform rough web pages into premium, polished interfaces with glassmorphism, Apple-inspired layouts, and three switchable themes.