Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →sickn33/saas-multi-tenant
Design and implement multi-tenant SaaS architectures with row-level security, tenant-scoped queries, shared-schema isolation, and safe cross-tenant admin patterns in PostgreSQL and TypeScript.
Passed 23 of 23 test cases with the skill, and 20 of 23 without it.
3 fixed20 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
Our team uses Prisma with Node.js and needs to enforce multi-tenancy rules across both incoming web requests and asynchronous queue workers. Could you write a TypeScript implementation guide with code snippets showing how to configure Prisma query extension/middleware to filter database queries automatically, alongside a strategy for passing tenant context into background queue jobs?
| Checked | Without skill | With skill |
|---|---|---|
| Recommends PostgreSQL Row-Level Security in addition to Prisma middleware for defense in depth | Missed | Passed |
| Instructs queue worker payloads to include tenant ID to set database context during task execution | Passed | Passed |
The instructions your model reads when the skill loads.
tenant_id columns to an existing single-tenant applicationDo NOT use this skill when:
Determine the tenancy model. Ask the user about their scale expectations and isolation requirements. For most SaaS apps under 1000 tenants, shared-schema with a tenant_id column on every table is the correct default. Schema-per-tenant adds operational overhead (migrations run N times). Database-per-tenant is only justified when tenants have regulatory data residency requirements.
Add tenant_id to every tenant-scoped table. The column must be NOT NULL, type UUID or TEXT, and included in every composite index. Never allow a tenant-scoped table to exist without this column — a missing tenant_id is a data leak waiting to happen.
Set up PostgreSQL Row-Level Security (RLS). Create a policy on each tenant-scoped table that filters rows by current_setting('app.current_tenant_id'). This acts as a database-level safety net — even if application code forgets a WHERE clause, RLS blocks cross-tenant reads.
Build tenant-aware middleware. At the start of every request, extract the tenant_id from the authenticated session or JWT claims. Set it on the database connection using SET LOCAL app.current_tenant_id = '...' inside a transaction. Every subsequent query in that request inherits the tenant scope automatically.
Scope all ORM queries by tenant. If using Prisma, apply a global middleware that injects where: { tenantId } into every findMany, findFirst, update, and delete call. If using Drizzle, create a base query builder that includes the tenant filter. Never rely on developers remembering to add the filter manually.
Handle tenant-aware migrations. Every new table migration must include tenant_id as a column. Write a linting rule or CI check that rejects any migration creating a table without tenant_id unless the table is explicitly marked as global (e.g., plans, feature_flags).
Build cross-tenant admin routes separately. Admin endpoints that aggregate data across tenants must bypass RLS explicitly using SET LOCAL role = 'admin_bypass' or a dedicated database role. These routes must be protected by a separate admin authentication flow — never reuse tenant user sessions for admin access.
Implement tenant provisioning. When a new customer signs up, create their tenant record, seed default data (roles, settings, onboarding state), and assign the founding user. Wrap this in a database transaction so partial provisioning never leaves orphan records.
test cases passed, vs 20 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.