メニュー
Use when an app has organizations/teams/workspaces — resolve the active tenant from the session or URL, scope every query to it, and guarantee one tenant can never read or write another's data.
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 | multi-tenancy |
| description | Use when an app has organizations/teams/workspaces — resolve the active tenant from the session or URL, scope every query to it, and guarantee one tenant can never read or write another's data. |
B2B SaaS is multi-tenant: users belong to organizations, and all data is owned by an org. The cardinal rule is isolation — no request may ever touch another tenant's rows. Use the shared-database, shared-schema model (an org_id column on every tenant table) and enforce scoping in one place: resolve the active org from the session, verify membership, and pass orgId into the data-access layer.
// src/server/auth/active-org.ts
import "server-only";
import { and, eq } from "drizzle-orm";
import { db } from "@/server/db/client";
import { memberships, organizations } from "@/server/db/schema";
import { requireSession } from "@/server/auth/require";
export async function requireOrg(slug: string) {
const session = await requireSession();
const [row] = await db
.select({ org: organizations, role: memberships.role })
.from(memberships)
.innerJoin(organizations, eq(memberships.orgId, organizations.id))
.where(and(eq(memberships.userId, session.user.id), eq(organizations.slug, slug)))
.limit(1);
if (!row) throw new Error("Not a member of this organization"); // 404/redirect
return { org: row.org, role: row.role, user: session.user };
}
Route by org in the URL — /(app)/[org]/... — and call requireOrg(params.org) in the layout so membership is checked before anything renders.
org_id (see data-access-layer).current_setting('app.org_id') policy, so even a buggy query can't cross tenants.orgId. Derive it from a verified membership, not a form field or header.org_id filter — one un-scoped query is a full cross-tenant breach. Centralize in the DAL.A verified { org, role, user } for the request. Feed role into authorization-rbac and org.id into every data-access-layer call.