frontend-onboardlisted

Make any existing frontend ready for the frontend toolkit (frontend-feature-planner, frontend-module-builder, frontend-test-writer, frontend-code-review) by establishing its contract files. Use this as the entry point whenever the user points the frontend toolkit at a directory — "set up my existing Next.js app for these skills", "onboard this React frontend", "I want to use these skills on my current UI", "get this client ready", or starting work in a frontend folder that has no ARCHITECTURE.md / MODULE_REGISTRY.md yet. For an EXISTING frontend it scans the repo and generates a DESCRIPTIVE ARCHITECTURE.md plus a MODULE_REGISTRY.md seeded with all existing reusable components, hooks, schemas, lib utils, and feature modules, so feature work reuses what's there instead of duplicating it (DRY). For an EMPTY directory it hands off to nextjs-bootstrap. It is non-destructive — it never refactors existing code, only writes the contract files. After onboarding, plan/build/test/review happen through the dedicated fron
vipincode/exr-agent-skills · ★ 0 · Web & Frontend · score 57

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

# frontend-onboard The single entry point for pointing the **frontend** toolkit at a directory. Its job is to produce the two contract files the rest of the frontend suite depends on — `ARCHITECTURE.md` and `MODULE_REGISTRY.md` — accurately reflecting *this* frontend, then route the user into the normal plan → build → test → review flow. It does **not** re-implement scaffolding, planning, building, testing, or reviewing — those are owned by `nextjs-bootstrap`, `frontend-feature-planner`, `frontend-module-builder`, `frontend-test-writer`, and `frontend-code-review`. This skill establishes the contract and delegates; that keeps the whole suite DRY instead of duplicating five skills into one. This is the frontend twin of `backend-onboard`. It mirrors that skill's philosophy exactly: **describe reality, never prescribe the bootstrap's defaults; seed the registry exhaustively so nothing gets built twice; touch nothing but the contract files.** Read `../NAMING.md` and `../LAYOUT.md` for how it coexists with a backend in one repo. ## Step 0 — Locate the project, then new-or-existing? First resolve **where the frontend code lives** — the *project dir* — because everything below reads and writes relative to it, while `.claude/` stays at the repo root. See `../LAYOUT.md`. - The project dir is the repo root if the app sits at the root, or a subfolder (e.g. `frontend-<name>/` like `frontend-shoply/`, or `frontend/`, `web/`, `client/`, `apps/web/`) if the user already keeps it th