菜单
Use when starting a new SaaS app or adding structure to one — sets up a Next.js (App Router) + TypeScript project with a sane folder layout, path aliases, server/client boundaries, and the conventions the rest of the stack builds on.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when building API endpoints or server actions — validate every input with zod, return consistent typed JSON errors, set correct status codes, and authenticate/authorize before touching data.
Use when adding sign-in/sign-up or session handling to a SaaS app — set up Auth.js (NextAuth) or a hosted provider with secure sessions, OAuth + email, and server-side session checks that protect routes and actions.
Use when controlling what a user may do — implement role-based access control with a central permission map, server-side checks on every mutation, and a typed `can()` helper instead of scattered role string comparisons.
Use when work shouldn't run in the request path — offload emails, webhooks, exports, and scheduled tasks to a queue or job runner with retries, idempotency, and dead-letter handling instead of blocking the user.
Use when querying or mutating the database from the app — wrap Drizzle in server-only, tenant-scoped functions instead of calling the ORM from components, so every read/write is typed, testable, and isolation-safe.
Use when designing the Postgres schema or setting up Drizzle ORM — model users, organizations, memberships, and tenant-scoped tables with the right keys, indexes, timestamps, and migrations from day one.
| name | project-scaffolding |
| description | Use when starting a new SaaS app or adding structure to one — sets up a Next.js (App Router) + TypeScript project with a sane folder layout, path aliases, server/client boundaries, and the conventions the rest of the stack builds on. |
A SaaS codebase lives or dies by its boundaries. Pick Next.js App Router + TypeScript and commit to one rule: business logic lives in server-only modules, the UI imports from a typed data-access layer, and secrets never cross into client components. Get the skeleton right and every later skill (auth, billing, jobs) slots in cleanly.
src/
app/ # routes (App Router)
(marketing)/ # public pages
(app)/ # authenticated app, wrapped in a layout that checks session
[org]/ # tenant-scoped routes (see multi-tenancy)
api/ # route handlers (webhooks, integrations)
server/ # SERVER-ONLY. never imported by client components
db/ # schema + drizzle client (database-schema)
services/ # business logic, one file per domain
auth/ # session helpers (authentication)
lib/ # isomorphic helpers (pure, no secrets)
components/ # UI (ui/* are shadcn primitives)
env.ts # typed env (environment-and-config)
import "server-only" at the top of every file in server/ — turns a leaked import into a build error.@/* → src/* in tsconfig.json so imports don't rot.server/services/billing.ts), called by actions and route handlers alike — never duplicate logic in the UI.strict: true plus "noUncheckedIndexedAccess": true in tsconfig from day one; retrofitting strictness is misery.npx create-next-app@latest --ts --app --tailwind --eslint
# then add: drizzle-orm + drizzle-kit, your auth lib, stripe, zod
Keep next.config minimal; add experimental.serverActions only if your version needs it.
utils.ts dumping ground — split lib/ (pure) from server/ (privileged).strict mode — every week without it adds any you'll never remove.A typed skeleton with clear server/client boundaries. Next: environment-and-config for typed secrets, then database-schema to model data.