メニュー
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.
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 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.
Use when shipping a SaaS app to production — set up CI checks, preview deploys, environment/secret management, database migrations on release, and the health checks and rollback path that make deploys boring.
| name | authorization-rbac |
| description | 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. |
Authentication says who you are; authorization says what you may do. Avoid if (role === "admin") sprinkled everywhere — it drifts and leaks. Define a single permission matrix mapping roles to actions, expose one typed can(role, action) helper, and call it on the server before every mutation. When rules outgrow roles, graduate to resource-level checks (ownership) without changing call sites.
// src/server/auth/permissions.ts
export type Role = "owner" | "admin" | "member";
export type Action =
| "project:create" | "project:delete"
| "member:invite" | "member:remove"
| "billing:manage";
const MATRIX: Record<Role, Action[]> = {
owner: ["project:create", "project:delete", "member:invite", "member:remove", "billing:manage"],
admin: ["project:create", "project:delete", "member:invite"],
member: ["project:create"],
};
export function can(role: Role, action: Action): boolean {
return MATRIX[role]?.includes(action) ?? false;
}
export function authorize(role: Role, action: Action): void {
if (!can(role, action)) {
const e = new Error("Forbidden");
(e as any).status = 403;
throw e;
}
}
Enforce in the action/handler, after resolving the tenant:
const { role, org } = await requireOrg(params.org);
authorize(role, "project:delete"); // throws 403 if not allowed
await deleteProject(org.id, projectId); // DAL still scopes by org_id
row.createdBy === user.id || can(role, ...).Action union.can() to hide buttons — but the server check is the real gate.multi-tenancy ensures it's your org's data; RBAC ensures you're allowed to act on it. You need both.?? false).A typed can() / authorize() enforced on the server. Pair with data-access-layer (which still scopes by org) and surface allowed actions to the UI.