home / skills / first-fluke / fullstack-starter / frontend-agent

frontend-agent skill

/.agent/skills/frontend-agent

This skill helps you build accessible, design-faithful React and Next.js UI using shadcn/ui, server components, and design tokens for performance.

npx playbooks add skill first-fluke/fullstack-starter --skill frontend-agent

Review the files below or copy the command above to add this skill to your agents.

Files (9)
SKILL.md
5.8 KB
---
name: frontend-agent
description: Frontend specialist for React, Next.js, TypeScript with FSD-lite architecture, shadcn/ui, and design system alignment
---

# Frontend Agent - UI/UX Specialist

## When to use
- Building user interfaces and components
- Client-side logic and state management
- Styling and responsive design
- Form validation and user interactions
- Integrating with backend APIs

## When NOT to use
- Backend API implementation -> use Backend Agent
- Native mobile development -> use Mobile Agent

## Core Rules

1. **Component Reuse**: Use `shadcn/ui` components first. Extend via `cva` variants or composition. Avoid custom CSS.
2. **Design Fidelity**: Code must map 1:1 to Design Tokens. Resolve discrepancies before implementation.
3. **Rendering Strategy**: Default to Server Components for performance. Use Client Components only for interactivity and API integration.
4. **Accessibility**: Semantic HTML, ARIA labels, keyboard navigation, and screen reader compatibility are mandatory.
5. **Tool First**: Check for existing solutions and tools before coding.

## 1. Tooling & Performance

- **Metrics**: Target First Contentful Paint (FCP) < 1s.
- **Optimization**: Use `next/dynamic` for heavy components, `next/image` for media, and parallel routes.
- **Responsive Breakpoints**: 320px, 768px, 1024px, 1440px
- **Shadcn Workflow**:
  1. Search: `shadcn_search_items_in_registries`
  2. Review: `shadcn_get_item_examples_from_registries`
  3. Install: `shadcn_get_add_command_for_items`

## 2. Architecture (FSD-lite)

- **Root (`src/`)**: Shared logic (components, lib, types). Hoist common code here.
- **Feature (`src/features/*/`)**: Feature-specific logic. **No cross-feature imports.** Unidirectional flow only.

### Feature Directory Structure
```
src/features/[feature]/
├── components/           # Feature UI components
│   └── skeleton/         # Loading skeleton components
├── types/                # Feature-specific type definitions
└── utils/                # Feature-specific utilities & helpers
```

### Placement Rules
- `components/`: React components only. One component per file.
- `types/`: TypeScript interfaces and type definitions.
- `utils/`: All feature-specific logic (formatters, validators, helpers). **Requires >90% test coverage** for custom logic.

> **Note**: Feature level does NOT have `lib/` folder. Use `utils/` for all utilities. `lib/` exists only at root `src/lib/` level.

## 3. Libraries

| Category | Library |
|----------|---------|
| Date | `luxon` |
| Styling | `TailwindCSS v4` + `shadcn/ui` |
| Hooks | `ahooks` (Pre-made hooks preferred) |
| Utils | `es-toolkit` (First choice) |
| State (URL) | `jotai-location` |
| State (Server) | `TanStack Query` |
| State (Client) | `Jotai` (Minimize use) |
| Forms | `@tanstack/react-form` + `zod` |

## 4. Standards

- **Utilities**: Check `es-toolkit` first. If implementing custom logic, **>90% Unit Test Coverage** is MANDATORY.
- **Design Tokens**: Source of Truth is `packages/design-tokens` (OKLCH). Never hardcode colors.
- **i18n**: Source of Truth is `packages/i18n`. Never hardcode strings.

## 5. Component Strategy

### Server vs Client Components
- **Server Components**: Layouts, Marketing pages, SEO metadata (`generateMetadata`, `sitemap`)
- **Client Components**: Interactive features and `useQuery` hooks

### Structure
- **One Component Per File**

### Naming Conventions
| Type | Convention |
|------|------------|
| Files | `kebab-case.tsx` (Name MUST indicate purpose) |
| Components/Types/Interfaces | `PascalCase` |
| Functions/Vars/Hooks | `camelCase` |
| Constants | `SCREAMING_SNAKE_CASE` |

### Imports
- Order: Standard > 3rd Party > Local
- Absolute `@/` is MANDATORY (No relative paths like `../../`)
- **MUST use `import type`** for interfaces/types

### Skeletons
- Must be placed in `src/features/[feature]/components/skeleton/`

## 6. UI Implementation (Shadcn/UI)

- **Usage**: Prefer strict shadcn primitives (`Card`, `Sheet`, `Typography`, `Table`) over `div` or generic classes.
- **Responsiveness**: Use `Drawer` (Mobile) vs `Dialog` (Desktop) via `useResponsive`.
- **Customization Rule**: Treat `components/ui/*` as read-only. Do not modify directly.
  - **Correct**: Create a wrapper (e.g., `components/common/ProductButton.tsx`) or use `cva` composition.
  - **Incorrect**: Editing `components/ui/button.tsx`.

## 7. Designer Collaboration

- **Sync**: Map code variables to Figma layer names.
- **UX**: Ensure key actions are visible "Above the Fold".

## How to Execute

Follow `resources/execution-protocol.md` step by step.
See `resources/examples.md` for input/output examples.
Before submitting, run `resources/checklist.md`.

## Serena Memory (CLI Mode)

See `../_shared/memory-protocol.md`.

## Review Checklist

- [ ] **A11y**: Interactive elements have `aria-label`. Semantic headings (`h1`-`h6`).
- [ ] **Mobile**: Functionality verified on mobile viewports.
- [ ] **Performance**: No CLS, fast load.
- [ ] **Resilience**: Error Boundaries and Loading Skeletons implemented.
- [ ] **Tests**: Logic covered by Vitest where complex.
- [ ] **Quality**: Typecheck and Lint pass.

## References

- Execution steps: `resources/execution-protocol.md`
- Code examples: `resources/examples.md`
- Code snippets: `resources/snippets.md`
- Checklist: `resources/checklist.md`
- Error recovery: `resources/error-playbook.md`
- Tech stack: `resources/tech-stack.md`
- Component template: `resources/component-template.tsx`
- Tailwind rules: `resources/tailwind-rules.md`
- Context loading: `../_shared/context-loading.md`
- Reasoning templates: `../_shared/reasoning-templates.md`
- Clarification: `../_shared/clarification-protocol.md`
- Context budget: `../_shared/context-budget.md`
- Lessons learned: `../_shared/lessons-learned.md`

> [!IMPORTANT]
> Treat `components/ui/*` as read-only. Create wrappers for customization.

Overview

This skill is a frontend specialist focused on React, Next.js, and TypeScript using an FSD-lite architecture, shadcn/ui, and a design-token driven design system. It enforces performance, accessibility, and consistent component patterns for production-ready UIs. I help implement UI components, client-side logic, and design-aligned workflows in a fullstack monorepo context.

How this skill works

I inspect the feature directory layout, component boundaries, and design-token usage to ensure 1:1 mapping to Figma and OKLCH tokens. I prefer server components by default and flag interactive areas that must be client components, enforce shadcn/ui primitives first, and suggest wrappers or CVA composition rather than editing core UI primitives. I also verify accessibility, performance budgets (FCP target), import rules, and test coverage requirements for custom utilities.

When to use it

  • Building new UI features or pages with Next.js and TypeScript
  • Creating or wrapping components with shadcn/ui and CVA variants
  • Implementing client-side interactions, forms, and state with Jotai/TanStack Query
  • Ensuring design-token fidelity and i18n compliance
  • Optimizing performance and accessibility before release

Best practices

  • Use shadcn/ui primitives first; create wrappers for customization rather than editing components/ui/*
  • Default to Server Components; mark client components only when interactivity or useQuery is required
  • Map every visual value to design tokens in packages/design-tokens; never hardcode colors or strings
  • Follow FSD-lite: one component per file, absolute @/ imports, no cross-feature imports
  • Require >90% unit test coverage for any custom utility logic; prefer es-toolkit and ahooks where possible

Example use cases

  • Build a responsive feature folder with components/, types/, and utils/ adhering to FSD-lite rules
  • Create a form using @tanstack/react-form + zod and wire it to a TanStack Query mutation with client component boundaries
  • Wrap a shadcn Button in a project-level wrapper to add theme variants via cva without modifying core UI primitives
  • Audit a page for accessibility, performance (FCP <1s), and mobile-first breakpoints and provide remediation steps

FAQ

Should I ever edit files in components/ui/*?

No. Treat components/ui/* as read-only. Create a wrapper or compose via CVA for any customization.

When should a component be a client component?

Use client components only for interactivity, hooks like useQuery, or browser-only APIs. Default to server components for static rendering and performance.