Menu
CSS design system principles — token usage, semantic layering, mobile-first, component isolation.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
MCP tool error response format — canonical error object, standard codes, retry semantics.
Run any question, idea, or decision through a council of 5 AI advisors who independently analyze it, peer-review each other anonymously, and synthesize a final verdict. Based on Karpathy's LLM Council methodology. MANDATORY TRIGGERS: 'council this', 'run the council', 'war room this', 'pressure-test this', 'stress-test this', 'debate this'. STRONG TRIGGERS (use when combined with a real decision or tradeoff): 'should I X or Y', 'which option', 'what would you do', 'is this the right move', 'validate this', 'get multiple perspectives', 'I can't decide', 'I'm torn between'. Do NOT trigger on simple yes/no questions, factual lookups, or casual 'should I' without a meaningful tradeoff (e.g. 'should I use markdown' is not a council question). DO trigger when the user presents a genuine decision with stakes, multiple options, and context that suggests they want it pressure-tested from multiple angles.
How agents, skills, and commands work in this project.
Documentation writing conventions — style, structure, tone, and quality standards.
GitHub conventions — branch naming, commit format, issue/PR templates, and safe issue/PR referencing in comments.
Logging conventions — level usage, formatting style, structured output.
| name | frontend-patterns |
| description | CSS design system principles — token usage, semantic layering, mobile-first, component isolation. |
| when_to_use | Working on CSS, styling, design tokens, or frontend component structure. |
| user-invocable | false |
Core principles for maintaining consistent, maintainable frontend code. Framework-agnostic — adapt examples to your stack.
Every design decision is defined exactly once. Design tokens live in the styles system. Components reference them, never redefine them.
/* Token file */
:root { --color-primary: #5b5956; }
/* Component */
.button { background: var(--color-primary); } /* yes */
.button { background: #5b5956; } /* no */
For JavaScript/SDK integrations, read tokens at runtime:
const primary = getComputedStyle(document.documentElement)
.getPropertyValue('--color-primary').trim();
SDK.configure({ buttonColor: primary }); /* yes */
SDK.configure({ buttonColor: '#5b5956' }); /* no */
If it's a design value, it's a variable. Colors, spacing, fonts, shadows, radii, and breakpoints are always variables — even if used once.
.card { padding: var(--space-xl); border-radius: var(--radius-lg); } /* yes */
.card { padding: 32px; border-radius: 12px; } /* no */
Every referenced variable must exist in the token files. Undefined variables fall back to browser defaults silently.
Exceptions: 0, single-pixel borders (1px), proportional values (100%), one-off transforms.
Base tokens -> Semantic tokens -> Component usage. Define primitives, map to purposes, use purposes in components.
/* Layer 1: Base primitives */
:root { --color-charcoal: #5b5956; }
/* Layer 2: Semantic purpose */
:root { --color-primary: var(--color-charcoal); }
/* Layer 3: Component usage */
.button { background: var(--color-primary); } /* yes — semantic */
.button { background: var(--color-charcoal); } /* no — base primitive */
CSS owns presentation. Never use inline styles. State changes toggle CSS classes, not inline styles.
/* yes — class-driven state */
.card.selected { border-color: var(--color-accent); }
/* no — inline style state */
/* style={selected ? 'border: 2px solid blue;' : ''} */
Exception: JavaScript-calculated values unknown at build time.
External integrations (third-party SDKs, embedded widgets) must read design tokens at runtime, not hardcode values. This keeps the design system as the single source of truth even across integration boundaries.
Components control their own structure (layout, flex, grid) but get their design values (colors, spacing, radii) from global tokens. Don't redefine token values inside components. Don't reach into child components with global selectors.
Base styles target mobile. Enhance upward with min-width media queries. Never use max-width.
.grid { grid-template-columns: 1fr; } /* mobile */
@media (min-width: 768px) {
.grid { grid-template-columns: repeat(2, 1fr); } /* desktop */
}
Desktop-first (max-width) leads to undoing styles at smaller sizes — harder to maintain and reason about.
Be clear about sizing, positioning, and state.
.container { max-width: var(--max-width); margin: 0 auto; } /* yes — explicit */
.container { width: 90%; } /* no — 90% of what? */
.modal { position: fixed; top: 50%; left: 50%; } /* yes — explicit */
.modal { position: absolute; } /* no — relative to what? */
Prefer boring, predictable patterns over novel solutions. When solving similar problems, use the same approach. Before creating a new pattern, check if an existing one can be adapted.
<!-- yes — consistent pattern for all cards -->
<div class="card"><h3 class="card-title">...</h3></div>
<!-- no — different naming for each similar component -->
<div class="service-box"><h3 class="service-heading">...</h3></div>
<div class="product-container"><h3 class="product-name">...</h3></div>