Create Auth Skill

Scaffolding skill for adding Better Auth to TypeScript/JavaScript apps. Two phases: plan (scan + ask), then implement. Don't skip planning.

Default stance

Scan first, ask second, code third. A "set up auth for me" request without a plan ends with the wrong adapter, the wrong framework integration, or features the user didn't actually want. The scan should auto-fill most answers; questions are only for what you couldn't detect.

Default to the minimum viable surface, then add plugins. Email/password + one OAuth provider is enough to ship. 2FA, organizations, magic link, passkey, SSO — add only when the user asks. Plugin churn means migration churn means user disruption.

For Seed-internal auth changes, use better-auth-best-practices instead — that skill knows the existing wiring. This skill is for new projects or projects without auth yet.

Use this skill when

The user is adding auth to a fresh TypeScript/JavaScript project, migrating from another auth library to Better Auth, or asking for a guided auth setup with detection of their framework/database/etc.

Phase 1: Plan

Scan

Detect:

• Framework — next.config.*, svelte.config.*, nuxt.config.*, astro.config.*, vite.config.*, Express/Hono entry files
• Database/ORM — prisma/schema.prisma, drizzle.config.*, deps (pg, mysql2, better-sqlite3, mongoose)
• Existing auth — next-auth, lucia, clerk, supabase/auth, firebase/auth in deps or imports
• Package manager — pnpm-lock.yaml, yarn.lock, bun.lockb, package-lock.json

Use what you find to skip questions you can already answer.

Ask

Use AskQuestion to ask all applicable questions in one call. Skip detected ones. Group under "Auth Setup Planning".

Core questions: project type, framework, database/ORM, auth methods (multi-select), social providers (only if OAuth selected), email verification, email provider, features/plugins (multi-select: 2FA, orgs, admin, bearer, password reset), auth pages, auth UI style.

Summarize

Present the plan as a markdown checklist. Get explicit confirmation before writing code.

Phase 2: Implement

Branches:

• New project — install, create auth.ts + auth-client.ts, route handler, env, run CLI generate/migrate, plugins, UI pages.
• Migration — install Better Auth alongside existing auth, migrate routes → session logic → UI, then remove the old library.
• Adding to existing — analyze structure, install, configure to match plan, integrate into existing pages, plugins.

End with explicit next-step guidance: OAuth credentials in provider dashboards, env vars in deploy target, flow testing.

Repo-aware variants

If you're scaffolding inside a Seed fork (or any project that already has lib/auth.ts), stop and use better-auth-best-practices. This skill assumes a green field and will conflict with the existing wiring.

Key snippets

// lib/auth.ts (Next.js + Drizzle + email/password + Google OAuth)
import { betterAuth } from "better-auth"
import { drizzleAdapter } from "better-auth/adapters/drizzle"
import { db } from "./db"

export const auth = betterAuth({
  database: drizzleAdapter(db, { provider: "pg" }),
  emailAndPassword: { enabled: true },
  socialProviders: {
    google: {
      clientId: process.env.GOOGLE_CLIENT_ID!,
      clientSecret: process.env.GOOGLE_CLIENT_SECRET!,
    },
  },
})

// app/api/auth/[...all]/route.ts
import { auth } from "@/lib/auth"
import { toNextJsHandler } from "better-auth/next-js"
export const { GET, POST } = toNextJsHandler(auth)

// lib/auth-client.ts
import { createAuthClient } from "better-auth/react"
export const { signIn, signUp, signOut, useSession } = createAuthClient()

Hard rules

• Don't write code in Phase 1. Plan first, code after explicit confirmation.
• Don't add plugins the user didn't ask for. Each plugin = schema change = migration. Add later.
• Don't pick the database adapter without scanning first. A wrong-adapter setup looks correct until the first session insert fails.
• Don't skip migrations. New project: run npx @better-auth/cli@latest migrate (or generate for Prisma/Drizzle) before declaring done.
• Don't disable security defaults to make a flow work. CSRF, origin check, secure cookies are all defaults for a reason.

Routing handler matrix

Framework	File	Handler
Next.js App Router	app/api/auth/[...all]/route.ts	toNextJsHandler(auth) → { GET, POST }
Next.js Pages	pages/api/auth/[...all].ts	toNextJsHandler(auth) (default export)
SvelteKit	src/hooks.server.ts	svelteKitHandler(auth)
Express	Anywhere	app.all("/api/auth/*", toNodeHandler(auth))
Hono	Route file	auth.handler(c.req.raw)

For Next.js Server Components, add nextCookies() plugin.

Where things live (in target project)

Recommended:

• lib/auth.ts — server config
• lib/auth-client.ts — client config
• app/api/auth/[...all]/route.ts (Next.js App Router) — handler
• app/(auth)/sign-in/page.tsx, sign-up/page.tsx — UI

Auxiliary content

• references/original-guide.md — full Better Auth scaffolding reference: scoped packages, route handlers per framework, common plugins, security checklist
• references/graph.md — handoff to better-auth-best-practices (for existing auth) and organization-best-practices (for multi-tenant)
• scripts/scan-auth-project.sh — detect framework, DB, ORM, package manager, existing auth library; run before asking questions
• assets/auth-plan-template.md — template for the implementation plan presented at end of Phase 1