clerk-production
Clerk in production: the choices its own skills cannot make
Clerk's own agent skills know the API. They cannot decide how your product uses it:
- where a session is verified, and what may read it;
- what a workspace is;
- where billing ends and authorization begins;
- which dashboard settings silently change what your code is allowed to do.
Those decisions are here, each with the incident that produced it.
They were learned on Next.js (App Router, Next 16, where middleware is proxy.ts) + Clerk Core 3 (@clerk/nextjs v7) + Supabase + Netlify, building several products with coding agents. Among them were a live Q&A product with organizations, a moderator role and paid plans, and a monitoring product with paid plans and API tokens, named here only by kind. Where Clerk's defaults or quickstarts contradict this skill, this skill wins. The authorization model these mechanics serve, which carries to any identity provider, is saas-authorization.
Three things of the product's own are named throughout. The integration notes are its dated record of how each provider is configured: instances, settings, slugs, read-backs. The permission module is the one module that maps roles to permission strings. The member home is the route sign-in lands on, /dashboard unless the product names another.