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/oleg494/coding-kit/design-systemnpx skills add oleg494/coding-kit --skill design-systemgit clone --depth 1 https://github.com/oleg494/coding-kitWhat 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.00046 | $0.00533 |
| Opus 5 | $0.00023 | $0.00267 |
| Sonnet 5 | $0.00009 | $0.00107 |
| Haiku 4.5 | $0.00005 | $0.00053 |
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 2d 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.
How it starts
The opening of the file, as written. The whole thing — 39 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Design System
Create the smallest visual source of truth that makes repeated UI decisions consistent. Prefer the project's existing component library and tokens; extend them only when the current system cannot express the required behavior.
Workflow
- Inventory first. Locate existing CSS variables, theme files, component primitives, typography rules, breakpoints, and brand references. Record what is already authoritative before adding a second source.
- Separate token layers. Keep raw primitives (palette, type sizes, spacing) separate from semantic roles (
surface,text,border,success,danger) and component decisions (button-primary-bg,table-row-hover). Components should consume semantic or component tokens, not scattered literals. - Define states explicitly. For each shared interactive component cover default, hover, active, focus-visible, disabled, loading, success, and error where applicable. State meaning must not depend on color alone.
- Define themes deliberately. Add light/dark or brand variants only when the product needs them. Keep contrast, forced colors, reduced motion, and readable disabled states in the token decisions.
- Keep the scale small. Establish one spacing scale, one type scale, a limited radius/elevation vocabulary, and a small semantic color set. Do not add a token for a single one-off value unless it represents a real design rule.
- Document usage, not decoration. For every token or component variant, state its purpose and when not to use it. Use product language and existing component names.
- Verify in context. Check representative dashboard screens in narrow and wide viewports, with long content and all important states. Remove duplicate tokens or abstractions that have no second consumer.
Defaults
- Semantic names over appearance names:
text-muted, notgray-500. - One source of truth for each color, type rule, spacing value, and component state.
- Existing primitives before new components.
- No raw hex values in product components when tokens are available.
- No global restyle when a local component variant closes the task.
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.
- 2d ago First seen · 39 lines · 46 tokens per session scan A 8c038ef97146
design-system is a skill published in the GitHub repository oleg494/coding-kit (1 stars, last pushed 3d ago), licensed MIT. It adds 46 tokens to every session and 533 once invoked, about $0.0002 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-08-31.
Other skills, from other repositories
design-audit
Design audit checklist - motion gaps, accessibility, color consistency, responsive, performance.
canvas-generative
Algorithmic and generative art with Canvas 2D - particles, flow fields, noise, fractals, L-systems.
css-native
Zero-dependency animations and visual techniques - scroll-driven, View Transitions, @starting-style, modern CSS.
cast
Cast genjutsu on a UI - creative coding for motion, micro-interactions, and wow-factor. Scans the stack, proposes an interaction thesis, loads the right sub-skills, implements the illusion. Adapts to Web, Android (Compose), Apple (SwiftUI).
tailwind-v4
Tailwind CSS v4 usage guide and v3-to-v4 differences. This skill should be used when writing, reviewing, or refactoring any Tailwind CSS code in this repo. Triggers on tasks involving Tailwind classes, @theme blocks, CSS-first configuration, or cleanup of v3-era syntax.
google-fonts-curator
Recommend high-taste Google Fonts for websites based on brand tone, page type, and visual direction. Use when the user needs font selection, font pairing, or aesthetic judgment within the Google Fonts ecosystem for landing pages, brand sites, editorial pages, portfolios, or digital products.