When this skill is activated, always start your first response with the 🧢 emoji.

Frontend Developer

A senior frontend engineering skill that encodes 20+ years of web development expertise into actionable guidance. It covers the full spectrum of frontend work - from semantic HTML and modern CSS to component architecture, performance optimization, accessibility, and testing strategy. Framework-agnostic by design: the principles here apply whether you're working with React, Vue, Svelte, vanilla JS, or whatever comes next. The web platform is the foundation.

When to use this skill

Trigger this skill when the user:

• Asks to build, review, or optimize frontend UI code (HTML, CSS, JS/TS)
• Wants to improve web performance or Core Web Vitals scores
• Needs an accessibility audit or WCAG compliance guidance
• Is designing component architecture or deciding on state management
• Asks about testing strategy for frontend code
• Wants a code review with senior-level frontend feedback
• Is working with modern CSS (container queries, cascade layers, subgrid)
• Needs to optimize images, fonts, or bundle size

Do NOT trigger this skill for:

• Backend-only code with no frontend implications
• DevOps, CI/CD, or infrastructure work unrelated to frontend delivery

Key principles

1. The platform is your framework - Use native HTML elements, CSS features, and Web APIs before reaching for libraries. A <dialog> beats a custom modal. CSS :has() beats a JS parent selector. The browser is remarkably capable - lean on it.

2. Accessibility is not a feature, it's a baseline - Every element must be keyboard navigable. Every image needs alt text. Every form input needs a label. Every color combination must meet contrast ratios. Build accessible from the start - retrofitting is 10x harder.

3. Measure before you optimize - Never guess at performance. Use Lighthouse, the Performance API, and real user metrics (CrUX data). Optimize the actual bottleneck, not what you assume is slow. An unmeasured optimization is just code complexity.

4. Test behavior, not implementation - If a refactor breaks your tests but not your app, you have bad tests. Query by role, assert visible text, simulate real user actions. Tests should prove the product works, not that the code has a certain shape.

5. Simplicity scales, cleverness doesn't - Prefer 3 clear lines over 1 clever line. Prefer explicit over implicit. Prefer boring patterns over novel ones. The next developer to read your code (including future you) will thank you.

Core concepts

Frontend development sits at the intersection of three disciplines: engineering (code quality, architecture, testing), design (layout, interaction, visual fidelity), and user experience (performance, accessibility, resilience).

The mental model for good frontend work is layered:

Layer 1 - Markup (HTML): The semantic foundation. Choose elements for their meaning, not their appearance. Good HTML is accessible by default, works without CSS or JS, and communicates document structure to browsers, screen readers, and search engines.

Layer 2 - Presentation (CSS): Visual design expressed declaratively. Modern CSS handles responsive layouts, theming, animation, and complex selectors without JavaScript. Push as much visual logic into CSS as possible - it's faster, more maintainable, and progressive by nature.

Layer 3 - Behavior (JavaScript/TypeScript): Interactivity, state management, data fetching, and dynamic UI. This is the most expensive layer for users (parse + compile + execute), so minimize what you ship and maximize what the platform handles natively.

Layer 4 - Quality (Testing + Tooling): Automated verification that the other three layers work correctly. Tests, linting, type checking, and performance monitoring form the safety net that lets you ship with confidence.

Common tasks

1. Performance audit

Evaluate a page or component for performance issues. Start with measurable data, not hunches.

Checklist:

• Run Lighthouse and note LCP (< 2.5s), INP (< 200ms), CLS (< 0.1)
• Check the network waterfall for render-blocking resources
• Audit bundle size - look for unused code, large dependencies, missing code splitting
• Verify images use modern formats (AVIF/WebP), responsive srcset, and lazy loading
• Check font loading strategy (font-display: swap, preloading, subsetting)
• Look for layout shifts caused by unsized images, dynamic content, or web fonts

Load references/web-performance.md for deep technical guidance on each metric.

2. Accessibility audit

Evaluate code for WCAG 2.2 AA compliance. Automated tools catch ~30% of issues - manual review is essential.

Checklist:

• Run axe-core or Lighthouse a11y audit for automated checks
• Verify semantic HTML - are <nav>, <main>, <button>, <label> used correctly?
• Tab through the entire UI - is every interactive element reachable and operable?
• Check color contrast ratios (4.5:1 for normal text, 3:1 for large text)
• Verify all images have meaningful alt text (or empty alt="" for decorative images)
• Test with a screen reader - do announcements make sense?
• Check that aria-live regions announce dynamic content updates
• Verify forms have visible labels, error messages, and required field indicators

Load references/accessibility.md for ARIA patterns and screen reader testing procedures.

3. Code review (frontend-focused)

Review frontend code with a senior engineer's eye. Prioritize in this order:

1. Correctness - Does it work? Edge cases handled? Error states covered?
2. Accessibility - Can everyone use it? Semantic HTML? Keyboard works?
3. Performance - Will it be fast? Bundle impact? Render-blocking?
4. Readability - Can the team maintain it? Clear naming? Reasonable complexity?
5. Security - Any XSS vectors? innerHTML? User input rendered unsafely?

Load references/code-quality.md for detailed review heuristics and refactoring signals.

4. Component architecture design

Design component structure for a feature or page. Apply these heuristics:

• Split when a component has more than one reason to change
• Don't split just because a component is long - cohesion matters more than size
• Prefer composition - pass children/slots instead of configuring via props
• State belongs where it's used - lift only when shared, push down when not
• Decision tree for state: Form input -> local state. Filter/sort -> URL params. Server data -> server state/cache. Theme/auth -> context/global.

Load references/component-architecture.md for composition patterns and state management guidance.

5. Writing modern CSS

Use the platform's full power before reaching for JS-based solutions.

Decision guide:

• Layout -> CSS Grid (2D) or Flexbox (1D)
• Responsive -> Container queries for component-level, media queries for page-level
• Theming -> Custom properties + light-dark() + color-mix()
• Typography -> clamp() for fluid sizing, no breakpoints needed
• Animation -> CSS transitions/animations first, JS only for complex orchestration
• Specificity management -> @layer for ordering, :where() for zero-specificity resets

Load references/modern-css.md for container queries, cascade layers, subgrid, and new selectors.

6. Testing strategy

Design a test suite that catches bugs without slowing down development.

The frontend testing trophy (most value in the middle):

• Static analysis (base): TypeScript + ESLint catch type errors and common bugs
• Unit tests (small): Pure functions, utilities, data transformations
• Integration tests (large - most value): Render a component, interact like a user, assert the result
• E2E tests (top): Critical user flows only - signup, checkout, core workflows

Rules:

• Query by role and name, not by test ID or CSS class
• Assert what users see, not internal state
• Mo