css-coder
CSS Coder
Guidance for writing CSS that prioritizes web standards, accessibility, performance, and maintainability.
Core Principles
- Web standards first — Use native CSS features before reaching for libraries or frameworks. No Tailwind, no CSS-in-JS unless explicitly requested.
- Accessibility as a requirement — Ensure styles support, never hinder, assistive technologies. Respect user preferences (motion, color scheme, contrast).
- Performance matters — Minimize repaints, avoid layout thrashing, use efficient selectors.
- Readable over clever — Future maintainers (including the author) should understand the code at a glance.
- Explicit over implicit — Avoid magic numbers and unexplained values. Use custom properties for shared values.
Workflow
- Check references first — Before writing CSS, consult
references/patterns.mdfor established patterns and snippets. - Validate against specs — When uncertain, reference MDN Web Docs or CSS specifications.
- Suggest alternatives — Offer ideas beyond the skill's patterns when appropriate, but always aligned with the core principles above.
Writing Guidelines
More from schalkneethling/webdev-agent-skills
frontend-security
Audit frontend codebases for security vulnerabilities and bad practices. Use when performing security reviews, auditing code for XSS/CSRF/DOM vulnerabilities, checking Content Security Policy configurations, validating input handling, reviewing file upload security, or examining Node.js/NPM dependencies. Target frameworks include web platform (vanilla HTML/CSS/JS), React, Astro, Twig templates, Node.js, and Bun. Based on OWASP security guidelines.
203semantic-html
Write well-considered semantic HTML that serves all users. Use when creating components, page structures, or reviewing markup. Emphasizes native HTML elements over ARIA. Treats proper document structure and accessibility as foundations rather than afterthoughts.
172css-tokens
Provides foundational CSS design tokens (custom properties) for typography, spacing, colors, borders, z-index, and transitions. Use when setting up a base token system for a web project.
17frontend-testing
Write tests that start with acceptance criteria, then add implementation tests for robustness. Use when writing unit tests (Vitest), end-to-end tests (Playwright), visual regression tests, or accessibility tests. Emphasizes user-centric testing, semantic locators, accessibility validation, and the balance between acceptance and implementation testing.
16component-scaffolding
Generate Drupal/Twig component skeletons with web components and Miyagi validation. Use when user requests to create, scaffold, or add a new component at a specific path (e.g., "add component skeleton at patterns/share-button"), or when creating component files including Twig templates, CSS, JavaScript web components, JSON schemas, or mock data files.
14component-usage-analysis
Analyse component dependencies and usage patterns in a Drupal/Twig component library. Use when user asks to find where a component is used, check if a component can be safely removed, audit component dependencies, find components using specific properties, or analyse impact of refactoring a component.
13