craft-frontend

Frontend Craft

This skill encodes one engineer's standard for structuring frontend application code, applied the same way across every repo. The method and opinions live here; the project specifics (which framework, which data library, which router) are discovered from the repo — never hardcoded or assumed.

Operating principle — discover before you build

Different repos already have different conventions. Before adding anything, spend two minutes mapping what exists so you extend rather than duplicate:

• package.json / lockfile → which framework (Next.js, React, Vue, Remix)? Which data layer (@tanstack/react-query, swr, RTK Query)? Which form lib (react-hook-form, Formik)? Which state approach (Zustand, Jotai, Context, URL-as-state)?
• grep for an existing API client, query key factory, or base hook — wire into it, don't fork it.
• Find the routing convention (file-based, config, nested layouts) and the client/server split strategy before deciding where new code lives.

State what you found, then propose the smallest set of additions that closes the gap.

The frontend layers (build in this order)

1. Component architecture — decide the composition shape first: where are the boundaries, what is server-rendered vs client-interactive, what gets co-located vs shared. Composition over configuration: a component that accepts children and slots is more reusable than one with 20 props. See references/architecture.md.

2. State — start local (useState), lift only when two siblings genuinely share it, reach for a global store only as a last resort. Server state (remote data) belongs in a query cache, not a store. See references/state.md.

3. Data fetching — use a typed client that matches the repo's existing pattern. Every fetch needs a loading state, an error state, and an empty state, all co-located with the component that owns the data. Avoid waterfall fetches: parallelize or prefetch where the router allows. See references/data-fetching.md.