craft-frontendlisted

The Craftsman standard for frontend application architecture — components, state management, data fetching, forms, routing, client/server boundaries, performance, error boundaries, and bundle size. Use this WHENEVER the work touches the application layer of a frontend: building or reviewing components, wiring up API calls, deciding where state lives, handling loading/error/ empty states, managing form validation, splitting bundles, or diagnosing slow pages. Trigger even when the user only says "wire up the API", "this page is slow", "manage this state", or "build the form" without naming a framework. NOTE: this skill covers the application-architecture layer (data, state, performance) — visual polish, design-system tokens, and layout decisions belong to craft-ux; the server/API implementation, authentication, and DB belong to craft-backend, craft-security, and craft-db (this skill owns the client side of the contract). Cross-reference those whenever both concerns appear in the same task.
atifgul99/craftsman-marketplace · ★ 1 · Web & Frontend · score 65

Install: claude install-skill atifgul99/craftsman-marketplace

# 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** —