菜单
Use when wiring up env vars, secrets, or runtime config — validate them with zod at boot, split server-only from public (NEXT_PUBLIC_) values, and fail fast with a clear error instead of a cryptic undefined at runtime.
用 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 | environment-and-config |
| description | Use when wiring up env vars, secrets, or runtime config — validate them with zod at boot, split server-only from public (NEXT_PUBLIC_) values, and fail fast with a clear error instead of a cryptic undefined at runtime. |
Untyped process.env is a runtime landmine: a missing STRIPE_SECRET_KEY shows up as undefined three layers deep at 2am. Validate the whole environment once at boot with zod, expose a typed env object, and make a misconfiguration a startup crash with an actionable message.
// src/env.ts
import { z } from "zod";
const server = z.object({
DATABASE_URL: z.string().url(),
AUTH_SECRET: z.string().min(32),
STRIPE_SECRET_KEY: z.string().startsWith("sk_"),
STRIPE_WEBHOOK_SECRET: z.string().startsWith("whsec_"),
RESEND_API_KEY: z.string().startsWith("re_"),
NODE_ENV: z.enum(["development", "test", "production"]).default("development"),
});
const client = z.object({
NEXT_PUBLIC_APP_URL: z.string().url(),
});
const parsed = server.merge(client).safeParse(process.env);
if (!parsed.success) {
console.error("❌ Invalid environment:", parsed.error.flatten().fieldErrors);
throw new Error("Invalid environment variables");
}
export const env = parsed.data;
Import env everywhere instead of process.env. TypeScript now knows every key exists and its type.
NEXT_PUBLIC_* vars reach the browser. Never prefix a secret with NEXT_PUBLIC_.client schema separate so it's obvious which values are public.import "server-only" in a env.server.ts and only merge public keys into a client-safe export..env.example with every key (empty or dummy values) — it's the contract for new devs and CI..env*.local to .gitignore; never commit real secrets.process.env directly — bypasses validation and types; you lose the safety net.NEXT_PUBLIC_ on a secret — it gets inlined into client JS and shipped to every visitor..env.example — onboarding becomes guesswork and CI breaks mysteriously.A typed env that the whole app trusts. database-schema, authentication, payments-stripe, and transactional-email all read their secrets from here.