Design and document Zero Trust security architecture for small businesses, clubs, NGOs, and hobby/side projects hosted on free or low-cost platforms (Vercel, Neon, Railway, Supabase, Cloudflare, PlanetScale, etc.). Use this skill whenever the user mentions: designing a system, setting up auth, protecting an API, securing a database, structuring roles/permissions, building a multi-tenant app, or phrases like "zero trust", "least privilege", "who can access what", "secure my app", "role-based access", "auth architecture", "API security", or "how should I structure my project security". Also trigger when the user describes a specific org type (business, club, school group, nonprofit, startup, side project) and wants to build something on Vercel, Neon, Supabase, Railway, or similar free-tier stacks. Always use this skill proactively — if the user is designing any kind of web app with users, roles, or data, this skill almost certainly applies.
"Never trust, always verify." Access is granted per-request, per-resource, per-role — never by network location.
| File | When to Read |
|---|---|
references/platform-configs.md | Detailed Vercel/Neon/Clerk/Supabase setup per tier |
references/auth-patterns.md | Code snippets: middleware, RLS, JWT, RBAC helpers |
references/security-checklist.md | Pre-launch and post-launch security checklist |
Read the relevant reference file(s) before generating implementation artifacts.
Guides the AI to produce a complete, opinionated Zero Trust architecture tailored to:
Before designing anything, gather this information. Ask only what isn't already clear from context:
1. Org type? (business / club / NGO / side-project / other)
2. What does the app do in one sentence?
3. Who are the user types? (e.g., admin, member, guest, staff, moderator)
4. What sensitive data exists? (payments, PII, medical, financial, none)
5. Stack preference? (Next.js / plain React / SvelteKit / other)
6. Auth preference? (Clerk / NextAuth / Supabase Auth / custom JWT / unsure)
7. Database? (Neon / Supabase / PlanetScale / SQLite / unsure)
8. Any existing code or is this greenfield?
If the user seems non-technical, simplify: ask about "who uses it" and "what's private" — skip stack questions and recommend defaults.
Based on intake, select one of three tiers:
references/platform-configs.md#tier-areferences/platform-configs.md#tier-breferences/platform-configs.md#tier-cGenerate a structured document with these sections:
references/auth-patterns.md for provider-specific snippetsDefine the permission matrix:
Role | Resource | Action | Condition
------------|-------------------|------------|------------------
admin | all | CRUD | org_id match
member | own_data | read/write | user_id match
guest | public_data | read | none
webhook_svc | event_table | insert | HMAC verified
Map this to:
references/auth-patterns.md#middleware)references/auth-patterns.md#rls)* for authenticated routesapp_user role: SELECT/INSERT/UPDATE on own rows onlyservice_role (server-side only): broader access, never in browser.env.local vs Vercel environment variables vs secrets manager.gitignore checklistFor each org tier, call out the top 5 realistic threats:
For each threat: likelihood (L/M/H), mitigation already covered, gaps remaining.
After the document, offer to generate any of the following:
middleware.ts with JWT/Clerk auth guardhasPermission(user, action, resource) utility.env.example with documentationnext.config.js or vercel.json security headersAsk the user which artifacts they want before generating.
Always end with a Free Tier Sustainability Check:
| Service | Free Limit | Risk if exceeded | Mitigation |
|---|---|---|---|
| Vercel | 100GB bandwidth/mo | Throttled | CDN caching, lazy load |
| Neon | 0.5GB storage, 1 CPU | Compute paused | Connection pool, indexes |
| Clerk | 10k MAU | Billing starts | Guest checkout fallback |
| Supabase | 500MB DB, 2GB egress | Project paused | Supabase branching |
disable RLS as a shortcut