メニュー
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.