RonanCodes/skills/nextjs

Next.js

Scaffold and build on the Next.js + Tailwind + shadcn/ui + Vercel stack, the Vercel-aligned alternative to the golden TanStack Start + Cloudflare default. Reach for this when the target is explicitly Next (a client on Next, or the HousApp stack: Next + Supabase + Vercel). For the canonical personal stack, use [/ro:new-tanstack-app] instead.

Usage

/ro:nextjs new <name>          # create-next-app (App Router, TS, Tailwind) + shadcn init
/ro:nextjs shadcn add button card table badge dialog   # add shadcn components
/ro:nextjs supabase            # wire Supabase + Drizzle into the app (defers to /ro:supabase)
/ro:nextjs deploy              # deploy to Vercel (uses VERCEL_TOKEN from ~/.claude/.env)
/ro:nextjs env                 # set up .env.local with the expected keys

Structural-change guard

Prompt the user (AskUserQuestion) before: create-next-app/pnpm add, shadcn init, creating a Vercel project, or the first deploy. They never invoke the skill internals directly.

Scaffold (the stack)

pnpm create next-app@latest <name> --ts --app --tailwind --eslint --src-dir --use-pnpm
cd <name>
pnpm dlx shadcn@latest init        # pick base colour / style; writes components.json
pnpm dlx shadcn@latest add button card table badge dialog input form sonner

Conventions to follow:

• App Router, src/app/. Server Components by default; add "use client" only where you need interactivity.
• Server Actions for mutations ("use server"), Route Handlers (app/api/.../route.ts) for webhooks/APIs.
• Tailwind + shadcn/ui for UI. Keep a small token layer (CSS vars in globals.css) so a brand palette (e.g. extracted client tokens) drops in cleanly.
• Keep secrets server-side; only NEXT_PUBLIC_* reaches the browser.

Data: Supabase + Drizzle

Next + Supabase is the common pairing. Defer DB ops to [/ro:supabase]; the split that works:

• Drizzle for schema + typed server queries (drizzle-kit for table migrations).
• supabase-js (@supabase/ssr) for RLS-aware, role-scoped reads (forwards the user JWT so policies apply).
• Supabase migrations hold the RLS policy SQL + auth triggers.
• Prisma is viable but its RLS story is awkward (own pooling, no clean per-request auth context) — prefer Drizzle here.

pnpm add drizzle-orm postgres @supabase/supabase-js @supabase/ssr
pnpm add -D drizzle-kit

Deploy to Vercel

export VERCEL_TOKEN=$(grep -E '^VERCEL_TOKEN=' ~/.claude/.env | cut -d= -f2-)
pnpm dlx vercel@latest --token "$VERCEL_TOKEN"            # first run: link/create project
pnpm dlx vercel@latest --prod --token "$VERCEL_TOKEN"     # production deploy
# env vars:
pnpm dlx vercel@latest env add NEXT_PUBLIC_SUPABASE_URL production --token "$VERCEL_TOKEN"

Custom domain (e.g. a subdomain on ronanconnolly.dev): add it in Vercel, point DNS (unproxied) at Vercel per the project's DNS skill.

When to choose this vs the golden stack

• This (Next + Vercel): the client/company is on Next; you want Vercel's preview deploys; pairing with Supabase. Aligns to a non-golden "house" stack on purpose.
• Golden ([/ro:new-tanstack-app]): your own personal/Simplicity builds — TanStack Start + Drizzle + Neon/Postgres + Cloudflare Workers.

Pairs with

• [/ro:supabase] — DB, Auth, RLS, types.
• [/ro:frontend-design] / [/artifact-design] — make the UI distinctive, not template-ish.
• [/ro:better-auth] if you want auth in your own tables instead of Supabase Auth.