frontend-module-builderlisted

Build the API binding for an already-designed Next.js/React feature from an approved FEATURE_PLAN — wiring the existing design to a real backend endpoint and making it functional, while enforcing reuse so no duplicate components, hooks, schemas, or utils get created. Use this whenever the user wants to implement/build/execute a planned frontend binding — "build the products binding", "implement FEATURE_PLAN_products.md", "now make this design functional", "wire up the orders screen", "bind it to the API". It reads the frontend ARCHITECTURE.md + MODULE_REGISTRY.md + the feature plan, searches for existing reusable code BEFORE creating anything, writes the feature-module binding layer (types/schema/api/hooks) and edits the built design to consume it (dropping hardcoded samples), unwraps the response envelope + validates with Zod, uses TanStack Query for server state, then updates the registry. It does NOT plan the binding (that is frontend-feature-planner), does NOT build/redesign components from Figma or HTML
vipincode/exr-agent-skills · ★ 0 · Web & Frontend · score 57

Install: claude install-skill vipincode/exr-agent-skills

# frontend-module-builder Execute an approved `_docs/FEATURE_PLAN_<name>.md` into working code: write the binding layer (types, Zod schemas, axios request fns, TanStack Query hooks) and wire the **already-built design** to it so the feature shows live data. Follow the project's conventions exactly and — critically — reuse what already exists instead of regenerating it. The two failure modes this skill exists to prevent: (1) **duplicating** a component/hook/util that already lives in `components/shared`, `lib`, `hooks`, or another feature, and (2) **rebuilding the design** instead of binding the one that's already there. The planner already mapped the design, the contract, and the reuse list — your job is to realize it faithfully, not re-decide it. ## Step 1 — Load everything **First resolve the project dir** for this (`frontend`) domain via `../LAYOUT.md` (read `.claude/workspace.json`; fall back to the repo root if a root `ARCHITECTURE.md` describing a Next.js/React app exists with no manifest). Everything below — the plan, the contract files, the dedup greps, the new/edited `src/` files, the registry — is **relative to that project dir**. 1. The feature plan: `_docs/FEATURE_PLAN_<name>.md` (planner docs live under `_docs/`). If none exists, stop and point the user to `frontend-feature-planner` — do not improvise a plan. **If the plan's status is `BLOCKED`**, do not build around the gap: surface the blocker (the missing API contract / prerequisite) and the unblock path