vipincode
UserAgent Skills for building production-grade Express + TypeScript + Mongoose backends with Claude Code
Categories
Indexed Skills (17)
express-ts-bootstrap
Scaffold a new production-grade Express.js + TypeScript + Mongoose + JOSE backend from scratch. Use this whenever the user wants to start a new Node/Express API project, bootstrap a backend, set up an Express + TypeScript starter, or initialize a server-side project — even if they only say "new API", "Express starter", "backend boilerplate", or name the stack loosely. This skill scaffolds the infrastructure ONCE per project and generates the two source-of-truth files (ARCHITECTURE.md and MODULE_REGISTRY.md) that the module-planner, module-builder, and test-writer skills depend on. Do NOT use this to add a feature to an existing project (that is module-planner + module-builder) or to write tests (test-writer). This scaffolds an Express/Node + TypeScript backend specifically — do NOT use it to bootstrap projects in other stacks or languages (Django/Python, Rails, Spring, Go, Next.js, etc.); those are out of scope.
figma-to-component
Turn a Figma frame or node (via the Figma MCP) into production-grade Next.js + TypeScript + Tailwind + shadcn/ui components, WITHOUT creating duplicates — it scans MODULE_REGISTRY.md and the shared/feature trees first and reuses or extends what exists, places each new piece correctly (generic/reusable → components/shared, domain-specific → features/<name>/components), styles with Tailwind utilities + theme tokens, animates with Tailwind/CSS or framer-motion, exports assets, and registers new shared components. Use this whenever the user wants to build/implement/convert a Figma design, frame, screen, section, or component into React/Next.js code — phrases like "turn this figma frame into a component", "build this design", "implement this figma node", "code this screen from figma", "figma to react/next", or pasting a figma.com link and asking for components. This is the Figma design-to-code component builder — when the design source is an HTML file/URL use html-to-component, and when it is another existing code
font-theme-setup
Extract a design system's tokens from a Figma file (via the Figma MCP) and apply them to a Next.js + Tailwind v4 + shadcn/ui project's THEME — rewriting globals.css color tokens in oklch, wiring fonts in layout.tsx (next/font Google + local custom fonts), and setting radius, shadows, spacing, line-heights, gradients, and background images. Use this whenever the user wants to set up or update the theme / design tokens / colors / typography / fonts from a Figma link — phrases like "set up the theme from this figma", "apply these design tokens", "update the colors and fonts from figma", "convert the palette to oklch", "configure the shadcn theme", or "wire up the fonts". This is the frontend theming skill — it edits globals.css + layout.tsx + tailwind theme, it does NOT build pages or components from a frame (that is figma-to-component) and does NOT scaffold the project (that is nextjs-bootstrap). Runs once per project (re-run to refresh tokens). Requires the Figma MCP to be connected and a Figma file/frame URL.
html-to-component
Turn an HTML file, a pasted HTML section, or a live URL into a production-grade Next.js + TypeScript + Tailwind + shadcn/ui design — in two phases. (1) THEME — extract the design's tokens (colors → oklch, typography, fonts, radius, shadows, spacing, gradients, background images) and apply them to globals.css + wire fonts in layout.tsx. (2) COMPONENTS — turn the markup into components WITHOUT creating duplicates, scanning MODULE_REGISTRY.md and the shared/feature trees first and reusing/extending what exists, placing generic pieces (header, navbar, hero, small-hero, carousel, charts, sidebar, avatar, logo, banner …) in components/shared and domain-specific ones in features/<name>/components, styling with Tailwind utilities + theme tokens, animating with Tailwind/CSS or framer-motion, and registering new shared components. Use this whenever the user wants to convert/implement/build HTML into React/Next.js — phrases like "turn this HTML into a component", "build this html section", "convert design.html to next.j
backend-code-review
Review backend / server-side code (Express, Node, TypeScript, Mongoose APIs) for correctness, security, convention adherence, and duplication. Use whenever the user asks to review, audit, critique, or sanity-check backend code — "review this service", "code review the auth module", "review my changes / this PR / the diff", "is this production-ready", "check this for issues". It reads ARCHITECTURE.md + MODULE_REGISTRY.md so it reviews against THIS project's conventions and flags code that duplicates existing registry entries (DRY). Standalone and read-only — run anytime, never auto-chained, and it does not modify source unless explicitly asked to apply fixes. Tuned for backend; not for frontend/React review. This is static code review only — it does NOT run the app or confirm a change behaves correctly at runtime; requests like "verify it works", "does it run", or "check that my change actually works" are run/verify intent (/verify or /run), not review.
backend-feature-planner
Plan a backend feature or module before any code is written. Use this whenever the user wants to add a feature, design a module (auth, products, orders, payments, search, file upload, etc.), or says things like "I want to build X", "plan the auth feature", "design the product module", or "how should I structure Y" for a server-side API. This is the BMAD replacement — it reads the project's ARCHITECTURE.md and MODULE_REGISTRY.md first, asks ONLY the questions those files don't already answer, and writes an editable FEATURE_PLAN markdown file. It does NOT write feature code (that is backend-module-builder) and does NOT write tests (that is backend-test-writer). Works in any project in the Express/TS convention family that has the contract files, or offers to create them for an existing repo.
backend-module-builder
Build a backend feature/module from an approved FEATURE_PLAN, enforcing reuse so no duplicate utils, middleware, types, or helpers get created. Use this whenever the user wants to implement, build, or generate a planned feature — "build the auth module", "implement FEATURE_PLAN_products.md", "now build it", "code up the orders feature". It reads ARCHITECTURE.md + MODULE_REGISTRY.md + the feature plan, searches for existing reusable code BEFORE creating anything, builds the module in the project's paradigm, then updates the registry. It does NOT plan features (that is backend-feature-planner) and does NOT write tests (that is backend-test-writer). Works in any project in the Express/TS convention family with the contract files.
backend-onboard
Make any project ready for the backend toolkit (backend-feature-planner, backend-module-builder, backend-test-writer) by establishing its contract files. Use this as the entry point whenever the user points the toolkit at a directory — "set up my existing API for this", "onboard this repo", "I want to use these skills on my current project", "get this project ready", or starting work in a folder that has no ARCHITECTURE.md / MODULE_REGISTRY.md yet. For an EXISTING codebase it scans the repo and generates a DESCRIPTIVE ARCHITECTURE.md plus a MODULE_REGISTRY.md seeded with all existing reusable code, so feature work reuses what's there instead of duplicating it (DRY). For an EMPTY directory it hands off to express-ts-bootstrap. It is non-destructive — it never refactors existing code, only writes the contract files. After onboarding, plan/build/test happen through the dedicated skills.
backend-test-writer
Write test cases for backend code on demand. Use this ONLY when the user explicitly asks to test something — "write tests for auth.service.ts", "test the product module", "add unit tests for this", "cover the order service". It is a standalone utility, run manually whenever the user wants — never auto-chained from backend-feature-planner or backend-module-builder. It reads ARCHITECTURE.md (conventions), MODULE_REGISTRY.md (what to mock vs use), and the actual target file(s), detects the test framework from package.json, and writes matching test files. It never modifies source files and never touches the registry. Works in any project in the Express/TS convention family.
frontend-code-review
Review frontend / client-side code (Next.js App Router, React, TypeScript, Tailwind + shadcn/ui, axios + Zod + TanStack Query + RHF) for correctness, component duplication, API-binding conformance, convention adherence, accessibility, and performance. Use whenever the user asks to review, audit, critique, or sanity-check frontend code — "review this component", "code review the products binding", "review my changes / this PR / the diff", "is this screen production-ready", "check this React code for issues". It reads the frontend ARCHITECTURE.md + MODULE_REGISTRY.md so it reviews against THIS project's conventions and flags components/hooks/utils that duplicate existing shared pieces or registry entries (DRY), plus bindings that bypass the BFF/axios/Zod/Query standard. Standalone and read-only — run anytime, never auto-chained, and it does not modify source unless explicitly asked to apply fixes. Tuned for frontend; NOT for backend/Express/Mongoose review (that is backend-code-review). This is static code revi
frontend-module-builder
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
frontend-onboard
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
frontend-test-writer
Write tests for frontend Next.js/React code on demand — components, hooks (incl. TanStack Query hooks), Zod schemas, and API-binding behavior. Use this ONLY when the user explicitly asks to test frontend code — "write tests for the products grid", "test the useProductsQuery hook", "add component tests for product-card.tsx", "cover the create-product form", "test this binding". It is a standalone utility, run manually whenever the user wants — never auto-chained from frontend-feature-planner or frontend-module-builder. It reads ARCHITECTURE.md (conventions), MODULE_REGISTRY.md (what to mock vs use), the target file(s), and the FEATURE_PLAN's testing checklist if present, detects the test framework + RTL setup from package.json, and writes matching test files. It never modifies source files and never touches the registry. It is NOT for backend tests (that is backend-test-writer). Frontend / Next.js / React / Vitest+RTL scope only.
nextjs-bootstrap
Scaffold a new production-grade Next.js (App Router) + TypeScript + Tailwind + shadcn/ui frontend from scratch, wired to a separate API backend (e.g. Express) via a BFF proxy, with axios, Zod, TanStack Query, and React Hook Form. Use this whenever the user wants to start a new Next.js / React frontend, bootstrap a web client/UI, set up a shadcn starter, or initialize a frontend project — even if they only say "new frontend", "Next.js starter", "React app", "admin dashboard UI", or name the stack loosely. It scaffolds the infrastructure ONCE per project and emits the two source-of-truth files (ARCHITECTURE.md and MODULE_REGISTRY.md) that module-planner, module-builder, test-writer, and code-review depend on. Do NOT use this to add a feature/page to an existing project (that is module-planner + module-builder) or to write tests. This scaffolds a Next.js + React frontend specifically — do NOT use it to bootstrap a backend/API (that is express-ts-bootstrap) or projects in other frontend stacks (Vite/CRA/Remix/Vue
prd-creator
Turn an app idea into a production-grade PRD, then shard it into per-module briefs that feed module-planner. Use this whenever the user wants to plan a whole app or product — "I want to build a blog / e-commerce app / SaaS", "create a PRD", "help me plan this app", "scope my product idea", "divide the PRD into modules", "shard the PRD" — or describes a product vision spanning multiple features, even if they never say "PRD". It takes the user's points, suggests improvements and standard production features they missed (auth, payments, admin, SEO — the user keeps or rejects each), writes _docs/prd/PRD.md, and on approval shards it into _docs/features/<module>/<module>-module.md briefs tagged backend/frontend/fullstack. Also use it to MODIFY an existing PRD (change scope, add features, re-shard). It does NOT do technical feature planning (that is module-planner), does NOT write code, and does NOT scaffold projects — product scope only, upstream of the whole toolkit.
project-to-component
Port a page, screen, or design language from ANY existing codebase into a production-grade Next.js + TypeScript + Tailwind + shadcn/ui page in the current project — the source being another repo/folder on disk (a static design mock, an old app, a legacy frontend — CSS Modules, styled-components, SCSS, plain CSS, Vue, older React/Next, or a Tailwind app with different conventions). Use this whenever the user points at an existing project as the design source — "copy the dashboard from <path/repo>", "port /admin/orders from our old app", "make this route match <project>", "rebuild this screen from <codebase>", "migrate these pages into the new frontend", "make our page look like project X". It reads the source READ-ONLY, derives a reusable translation map (source colors/fonts/spacing → the target's oklch theme tokens; source custom UI → shadcn/ui + shared components), lifts the source theme first when the target still has the stock shadcn theme, then builds dedup-first — scanning ARCHITECTURE.md + MODULE_REGIST
test-writer
Write tests on demand for whatever the user points at — backend services, controllers, routes, and integration paths, or frontend components, hooks, schemas, and bound screens. Use this ONLY when the user explicitly asks for tests — "write tests for auth.service.ts", "test the product module", "add component tests for product-card.tsx", "cover the create-product form", "test the useProductsQuery hook", "test this binding", "write tests for the slice I just built". It is a standalone utility run manually — never auto-chained from module-planner or module-builder, though module-builder will suggest it once a slice lands. It infers the domain from the target's path, reads ARCHITECTURE.md for conventions (the real response envelope, error model, data-fetching approach) and MODULE_REGISTRY.md for which collaborators are real shared pieces worth mocking faithfully, detects the installed test framework and mocking setup from package.json rather than assuming one, and reads the slice's Testing checklist from _docs/fe
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.