Generate production-ready frontend code. Use for components, pages, routes, client state, forms, styling, accessibility, performance, PWA behavior, and data visualization.
Instalación
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Generate production-ready frontend code. Use for components, pages, routes, client state, forms, styling, accessibility, performance, PWA behavior, and data visualization.
Implement production frontend work by routing to the smallest relevant reference set, matching the repository's existing architecture, and verifying the user-facing behavior.
Variant Detection
User signals: Look for framework names, route or page names, component libraries, state libraries, CSS systems, test tools, file paths, file extensions, and requested user-facing behavior.
Repository signals: Inspect package.json, lockfiles, framework configs, tsconfig.json, source folders, imports, routing structure, design tokens, Storybook, test setup, and CI jobs before choosing an implementation path.
Frontend scope: Use this skill for components, pages, layouts, routes, loaders/actions, forms, stores, queries, charts, responsive styling, accessibility fixes, PWA behavior, and frontend performance work.
Route away: Use code-tests for test-only work, design-api for API contract design, code-backend for backend implementation, and write-spec or a design skill for UI/UX specification when no code is requested.
Clarify rarely: If the framework, styling system, or target surface remains genuinely ambiguous after inspection, ask one short question naming the likely options.
Service workers, manifest, offline mode, installability
references/pwa.md
Charts, dashboards, dense tables, interactive data
references/visualization.md
Implementation Workflow
Inspect first: Identify the existing component boundaries, route conventions, data-fetching layer, state model, styling approach, design tokens, lint rules, and accessibility patterns before editing.
Keep scope tight: Make the smallest change that completes the requested behavior. Avoid new providers, stores, component layers, UI kits, icon sets, chart libraries, or form libraries unless the request or repository already points there.
Place code deliberately: Put reusable primitives near the existing design system, route-specific composition near routes or pages, and side effects in the established data, loader, action, hook, service, or store layer.
Model states explicitly: Implement applicable loading, empty, error, success, disabled, optimistic, validation, permission, and offline states. Do not ship decorative placeholders for requested product behavior.
Preserve visual language: Match existing typography, spacing, color tokens, icon conventions, motion, density, and component APIs. Prefer project-owned abstractions when they already fit.
Design for change: Keep components cohesive, props explicit, dependencies local or injected through existing mechanisms, and shared logic extracted only when it removes meaningful duplication.
Working Rules
Accessibility: Use semantic elements, labels, keyboard navigation, visible focus, reduced-motion behavior, useful alt text, and status announcements where needed. Accessibility is implementation work, not a final checklist.
Responsive layout: Use stable constraints such as grid tracks, flex rules, aspect ratios, min/max sizes, and explicit wrapping. Avoid text overlap, layout shift, viewport-scaled typography, and controls that resize unpredictably.
Forms: Validate at the UI boundary, expose errors accessibly, preserve dirty and pending state, and keep client-side validation consistent with server constraints. Never rely on frontend checks as the only enforcement for authorization or sensitive rules.
State: Keep local state local. Use existing query, cache, store, loader, action, or context patterns for shared state, server state, optimistic updates, and invalidation.
Performance: Avoid unnecessary client JavaScript, repeated expensive renders, unbounded lists, layout thrashing, oversized assets, and avoidable bundle growth. Defer deeper optimization until measurement or risk justifies it.
Tests: Add or update focused tests when the repository has a frontend test setup. Prefer component, interaction, route, accessibility, or visual-regression coverage that exercises behavior over shallow render-only tests.
Verification: Run the narrowest relevant formatter, linter, typecheck, build, and tests available. For browser-visible changes, inspect the running UI when practical and check responsive breakpoints that matter.
Output
When editing a repository, finish with changed files, commands run, and verification status. Mention commands that could not be run and why.
