Frontend engineering
Frontend engineering methodology — component architecture, state management, API integration, responsive layout, client-side performance, and frontend testing patterns. Framework agnostic, focused on web frontend implementation.From its SKILL.md
npx -y skills add magnus919/agent-skills --skill frontend-engineeringAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 29 days oldThe repository was created 29 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 21 stars21 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its file declares
Copied from the file, not written here
The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
4.3 KB, 739 tokens by cl100k_base, as published. Nobody here has run it
Frontend Engineering Methodology
Frontend engineering is the craft of building the user-facing layer of applications — components, state management, API integration, responsive layout, and client-side performance. This methodology bridges UX design (user journeys, wireframes, accessibility standards) and the reviewer (code quality gate).
The Frontend Engineer's Domain
| You own | You don't own |
|---|---|
| Component implementation — UI component composition, props/state interfaces, rendering patterns, lifecycle | User journeys, wireframes, accessibility standards, interaction design — that's the ux-designer |
| State management — client-side state architecture, data fetching patterns, caching, optimistic updates | API contract design — that's the technical-architect |
| API integration — frontend-to-backend data flow, auth flows (OAuth, JWT), real-time updates | Test strategy and automation — that's the QA-engineer |
| Responsive design implementation — layout systems, breakpoints, cross-device testing | Visual identity and brand guidelines — that's the brand-designer |
| Client-side performance — bundle optimization, lazy loading, Core Web Vitals, render optimization | Editorial content and copy — that's the writer |
| Frontend testing — component tests, integration tests, visual regression, accessibility tests | Code review and quality gates — that's the reviewer |
| Build tooling — bundler config, TypeScript config, linting, formatting, dev environment | CI/CD pipeline infrastructure — that's the platform-engineer |
Reference Files
| Reference | When to load |
|---|---|
references/component-architecture.md | Designing component trees — composition patterns, props/state interfaces, lifecycle, accessibility fundamentals |
references/state-management.md | Choosing and implementing state management — client vs server state, data fetching, caching, optimistic updates |
references/api-integration.md | Connecting frontend to backend — API client design, auth token flow, error handling in the UI, real-time subscriptions |
references/responsive-layout-testing.md | Implementing responsive designs (layout system selection — Grid vs Flexbox vs Container Queries, breakpoint strategies, cross-device testing methodology) and testing frontend code (component testing with Testing Library, integration testing with Playwright/Cypress, visual regression, accessibility testing with axe-core and Lighthouse CI, test data management) |
references/performance.md | Optimizing client-side performance — Core Web Vitals, bundle analysis, code splitting, render optimization |
Core Principles
Components are the unit of composition, not pages — Design and build components as reusable, composable units. Pages are assembled from components, not built as monoliths. A well-designed component can be reused in contexts its creator never imagined.
Co-locate state with the components that need it — Not every piece of state belongs in a global store. Local state stays local. Server state is fetched and cached. Only truly shared application state belongs in a global context.
Design for every state, not just the happy path — Every data-dependent component has at least four states: loading, empty, error, and success. Designing for all four is not a nicety — it creates a resilient user experience.
Accessibility is not a feature, it's a requirement — Keyboard navigation, screen reader support, color contrast, and focus management are not enhancements. They are part of the implementation contract.
Performance is a UX concern — Every millisecond of load time, every layout shift, every janky interaction erodes user trust. Performance budgeting, bundle analysis, and render optimization are part of frontend engineering, not an afterthought.
What ships with it: 11 files
70.4 KB alongside SKILL.md, 2 of them executable
evals/
- evals.json10.4 KB
references/
- api-integration.md1.6 KB
- component-architecture.md1.8 KB
- performance.md1.4 KB
- responsive-layout-testing.md31.6 KB
- state-management.md1.8 KB
scripts/
- bundle-budget-checker.pyruns6.3 KB
- test_bundle_budget_checker.pyruns7.9 KB
templates/
- README.md2.0 KB