How to use
- Copy the installation command and review the source package before installing it in your own agent environment.
- Check the source document for required tools, credentials and supported hosts.
- Describe your input and desired deliverable; review the output against the source material.
npx skills add https://github.com/helderberto/agent-skills --skill frontend-ui-engineeringBefore you start
- Installation does not include a model subscription, API allowance or permission to access your files.
- Repository stars and installation counts describe activity, not an independent quality or security test.
Original skill document
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
Frontend UI Engineering
Decide how to structure a UI unit before writing it, so the choices audits would catch late (accessibility, i18n, bundle cost, missing states) are made up front. Frontend counterpart to codebase-design: a component is a deep module — a lot of behaviour behind a small prop surface. This skill decides; tdd/build implement; the audit skills verify. Framework-agnostic.
1. Classify the unit
| Kind | Emphasis |
|---|---|
| Design-system primitive (Button, Input) | prop API, variants via props, tokens, a11y contract |
| Composite component | composition, state placement, required states |
| Page / route | data-fetching boundary, layout, loading/error at the route |
| Refactor of existing UI | shrink prop surface, extract states, remove magic values |
2. Decision pass — state each choice before coding
- Boundary & prop API. Smallest surface that serves callers. Prefer composition (
children/slots) over configuration. A growing set of boolean flags (isPrimary,isSmall,isLoading…) is a smell — three booleans is eight states, most untested; reach for avariant/sizeunion or composition. - Where state lives. The lowest owner that still works: local → lifted → server state → URL. No derived state stored twice; compute from source.
- Data & async. Decide the fetch boundary (route/loader vs. inside the component) and who owns caching. Keep rendering components separate from fetching ones where practical.
- Required UI states. Enumerate and design loading, empty, error, disabled (and partial/optimistic where relevant) now. Happy-path-only is unfinished.
- Styling. Design-system tokens, no magic colors/spacing. Variants through props, not one-off overrides.
- Responsive. Mobile-first; intentional breakpoints; no fixed widths that break small screens.
- Accessibility by construction. Semantic HTML first, ARIA last; keyboard + focus order; a label for every control; visible focus. Full WCAG pass belongs to
a11y-audit. - User-facing strings. Through the project's i18n path from the start. Coverage check belongs to
i18n.
3. Build and hand off
Apply the decisions. Call the Skill tool with tdd for non-trivial logic and its tests, then with visual-review in UI mode for before/after in a real browser. /hb:review then runs the audits as the QA pass before /hb:to-pr.
