Add Clerk authentication to a Next.js App Router project with middleware, route protection, session-aware UI, environment hygiene, and production auth safety checks.
The download URL is Clerk's external JavaScript SDK source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows., Clerk middleware does not protect routes by default; require an explicit protected-route matcher before assuming a page, API route, or tRPC endpoint is private., Do not commit `CLERK_SECRET_KEY`, webhook signing secrets, OAuth provider secrets, or copied dashboard values to source control, issue comments, screenshots, or chat transcripts., Review middleware matchers carefully. A broad matcher can affect static assets and public routes, while a narrow matcher can leave sensitive routes unauthenticated., Treat organization roles, custom permissions, and metadata checks as authorization logic that needs tests, not just UI hiding., Webhook handlers can mutate user, membership, subscription, and organization state. Make handlers idempotent and verify signatures before processing events., Confirm production domains and redirect URLs before deploy; wrong origins can break sign-in, leak users into the wrong environment, or create confusing callback loops.
Privacy notes
Clerk processes user identity, email addresses, sessions, cookies, authentication factors, OAuth profile data, organization membership, and optional user metadata., Application logs, error reports, webhook payloads, request traces, and AI chat transcripts can retain user IDs, email addresses, session state, redirect URLs, or organization names., Keep public examples synthetic. Do not paste real Clerk keys, dashboard screenshots, webhook payloads, user records, or organization metadata into prompts or PRs., Review Clerk, deployment-provider, analytics, and AI-assistant retention policies before using real customer identity data in troubleshooting sessions., If custom metadata stores roles, billing flags, internal account IDs, or entitlement data, treat it as sensitive authorization data and avoid exposing it client-side unless intended.
7 safety and 5 privacy notes across 4 risk areas. Review closely: credentials & tokens, permissions & scopes, network access.
4 areas
SafetyNetwork accessThe download URL is Clerk's external JavaScript SDK source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows.
SafetyNetwork accessClerk middleware does not protect routes by default; require an explicit protected-route matcher before assuming a page, API route, or tRPC endpoint is private.
SafetyCredentials & tokensDo not commit `CLERK_SECRET_KEY`, webhook signing secrets, OAuth provider secrets, or copied dashboard values to source control, issue comments, screenshots, or chat transcripts.
SafetyGeneralReview middleware matchers carefully. A broad matcher can affect static assets and public routes, while a narrow matcher can leave sensitive routes unauthenticated.
SafetyPermissions & scopesTreat organization roles, custom permissions, and metadata checks as authorization logic that needs tests, not just UI hiding.
SafetyNetwork accessWebhook handlers can mutate user, membership, subscription, and organization state. Make handlers idempotent and verify signatures before processing events.
SafetyGeneralConfirm production domains and redirect URLs before deploy; wrong origins can break sign-in, leak users into the wrong environment, or create confusing callback loops.
PrivacyCredentials & tokensClerk processes user identity, email addresses, sessions, cookies, authentication factors, OAuth profile data, organization membership, and optional user metadata.
PrivacyCredentials & tokensApplication logs, error reports, webhook payloads, request traces, and AI chat transcripts can retain user IDs, email addresses, session state, redirect URLs, or organization names.
PrivacyNetwork accessKeep public examples synthetic. Do not paste real Clerk keys, dashboard screenshots, webhook payloads, user records, or organization metadata into prompts or PRs.
PrivacyCredentials & tokensReview Clerk, deployment-provider, analytics, and AI-assistant retention policies before using real customer identity data in troubleshooting sessions.
PrivacyPermissions & scopesIf custom metadata stores roles, billing flags, internal account IDs, or entitlement data, treat it as sensitive authorization data and avoid exposing it client-side unless intended.
Safety notes
The download URL is Clerk's external JavaScript SDK source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows.
Clerk middleware does not protect routes by default; require an explicit protected-route matcher before assuming a page, API route, or tRPC endpoint is private.
Do not commit `CLERK_SECRET_KEY`, webhook signing secrets, OAuth provider secrets, or copied dashboard values to source control, issue comments, screenshots, or chat transcripts.
Review middleware matchers carefully. A broad matcher can affect static assets and public routes, while a narrow matcher can leave sensitive routes unauthenticated.
Treat organization roles, custom permissions, and metadata checks as authorization logic that needs tests, not just UI hiding.
Webhook handlers can mutate user, membership, subscription, and organization state. Make handlers idempotent and verify signatures before processing events.
Confirm production domains and redirect URLs before deploy; wrong origins can break sign-in, leak users into the wrong environment, or create confusing callback loops.
Privacy notes
Clerk processes user identity, email addresses, sessions, cookies, authentication factors, OAuth profile data, organization membership, and optional user metadata.
Application logs, error reports, webhook payloads, request traces, and AI chat transcripts can retain user IDs, email addresses, session state, redirect URLs, or organization names.
Keep public examples synthetic. Do not paste real Clerk keys, dashboard screenshots, webhook payloads, user records, or organization metadata into prompts or PRs.
Review Clerk, deployment-provider, analytics, and AI-assistant retention policies before using real customer identity data in troubleshooting sessions.
If custom metadata stores roles, billing flags, internal account IDs, or entitlement data, treat it as sensitive authorization data and avoid exposing it client-side unless intended.
Prerequisites
Next.js App Router project or migration branch.
Clerk account and application for the target environment.
`NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY` and `CLERK_SECRET_KEY` available through local and deployment environment configuration.
Route map that separates public pages, protected app pages, API routes, and admin or organization-scoped areas.
Decision on whether to use Clerk hosted Account Portal pages, custom sign-in/sign-up pages, or both.
Production domain, redirect URL, callback URL, and allowed origin plan.
.gemini/skills/<skill-name>/SKILL.md or .agents/skills/<skill-name>/SKILL.md
cursor
Adapter
.cursor/rules/<skill-name>.mdc
cli
Manual
AGENTS.md or tool-specific context file
Full copyable content
# Trigger
"Apply the Clerk Next.js authentication skill to this app."
# Required output
1) Current app/router/auth surface inventory
2) Clerk package, env, provider, and middleware changes
3) Protected route and UI component plan
4) Safety, privacy, webhook, and production redirect checks
About this resource
Knowledge Freshness
This skill is based on Clerk's Next.js quickstart and clerkMiddleware()
reference reviewed on 2026-06-04. The quickstart currently installs
@clerk/nextjs, adds NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY and
CLERK_SECRET_KEY, configures clerkMiddleware(), wraps the app with
<ClerkProvider>, and uses Clerk UI helpers such as <SignInButton>,
<SignUpButton>, and <UserButton>.
Prefer the live Clerk docs and clerk/javascript repository over model memory
for package names, middleware filenames, route matcher examples, and SDK
changes.
Scope Note
Use this skill for Clerk-backed authentication in a Next.js App Router project.
It is not a generic auth architecture guide and it should not replace a product
security review for high-risk admin, healthcare, finance, education, or
enterprise identity workflows.
Core Workflow
Inventory the existing Next.js structure, router type, /src usage, public
pages, protected pages, API routes, tRPC routes, admin areas, and organization
boundaries.
Confirm the target Clerk application, environment, domain, allowed origins,
sign-in/sign-up strategy, and whether users will rely on hosted Account
Portal pages or custom pages.
Add @clerk/nextjs with the project's package manager and document the
required local, preview, staging, and production environment variables.
Add Clerk middleware in the correct root or src location for the current
Next.js version, then keep the matcher explicit enough to avoid accidental
static-asset or public-route side effects.
Build the protected-route matcher from the route inventory instead of
guessing. Include app pages, API routes, and tRPC paths that require auth.
Wrap the root layout with <ClerkProvider> and add signed-in and signed-out
UI states using Clerk components or project-specific wrappers.
Add server-side user/session access only where needed, and keep authorization
checks close to the data or action being protected.
Review organization roles, custom permissions, metadata reads, and billing or
entitlement checks as authorization logic that needs test coverage.
If webhooks are used, verify event signatures, make processing idempotent,
and store only the user or organization fields the app actually needs.
Produce a rollout plan with local sign-up, sign-in, sign-out, protected
route, API-route, organization, and production redirect checks.
Required Inputs
Next.js version, router mode, package manager, and whether the project uses
a /src directory.
List of public routes, authenticated user routes, admin routes, API routes,
and organization-scoped routes.
Clerk application/environment name and approved local, preview, staging, and
production domains.
Sign-in/sign-up page decision: Account Portal, custom pages, or a hybrid.
User data model, metadata fields, organization roles, custom permissions, and
webhook event requirements.
Deployment platform and secret-management path.
Production Rules
Do not assume middleware protects anything until the protected matcher and a
negative unauthenticated test prove it.
Keep CLERK_SECRET_KEY server-only. Only NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY
belongs in client-exposed configuration.
Avoid UI-only access control. Protect server actions, API handlers, tRPC
procedures, loaders, and database writes at the server boundary.
Keep authorization policy explicit when roles or organization membership
influence access. Hidden buttons are not permission checks.
Use synthetic users for demos, screenshots, bug reports, and AI prompts.
Treat Clerk dashboard changes as production configuration changes and record
them alongside code deploys.
Confirm redirect URLs and allowed origins for every deployment environment
before merging auth changes.
Compatibility
Native
Claude Code / Claude: use as a reusable Agent Skill for auth integration
planning, route review, and implementation guidance.
Codex/OpenAI workflows: use as SKILL.md-style instructions when editing
Next.js apps and reviewing Clerk auth changes.
Manual Adaptation
Cursor, Windsurf, Gemini, and Generic AGENTS files: adapt the trigger,
workflow, safety notes, and output contract into repository-level auth rules.
Output Contract
Source evidence: Clerk docs and SDK repo URLs reviewed, with date.
App inventory: router, routes, API boundaries, auth gaps, and deployment
environments.
Safety and privacy review: secrets, webhook signatures, route protection,
metadata exposure, logs, and real-user data handling.
Validation checklist: sign-up, sign-in, sign-out, protected page, protected
API route, organization access, redirect URLs, and production smoke checks.
Duplicate And Source Review
Current HeyClaude content already mentions Clerk inside a generic subagent
factory example, but there is no dedicated Clerk, @clerk/nextjs, or
clerk/javascript content entry. This skill is specifically scoped to the
official Clerk Next.js SDK workflow and is source-backed by Clerk's current docs
and official JavaScript SDK repository.
Troubleshooting
Issue: A protected page is still public
Fix: Check that the route is included in the protected matcher and that the
middleware file is in the correct root or src location for the app.
Issue: Static assets, images, or public pages behave strangely after adding
middleware
Fix: Revisit the matcher. Skip Next.js internals and static files while
still including API and auth-related routes that need Clerk state.
Issue: Sign-in works locally but fails in preview or production
Fix: Compare Clerk dashboard domains, callback URLs, allowed origins,
environment variables, and deployment-provider secret names for that exact
environment.
Issue: Users can see UI for actions they cannot perform
Fix: Move the authorization check to the server action, API handler, tRPC
procedure, or database write path, then keep UI hiding as a convenience only.
Issue: Webhook processing creates duplicate rows or stale user state
Fix: Verify signatures, store event IDs or idempotency keys, and make
handlers safe to replay before processing production events.
Show that Clerk Next.js Authentication Skill is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/skills/clerk-nextjs-authentication)
How it compares
Clerk Next.js Authentication Skill side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
Add Clerk authentication to a Next.js App Router project with middleware, route protection, session-aware UI, environment hygiene, and production auth safety checks.
Add Better Auth to a Next.js App Router project with API route handlers, database-backed sessions, client helpers, protected route checks, and production auth safety review.
Add or maintain next-intl internationalization in a Next.js App Router project with messages, request configuration, locale-based routing, proxy or middleware behavior, Server and Client Components, typed message keys, localized navigation, SEO review, testing, and rollout planning.
✓The download URL is Clerk's external JavaScript SDK source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows.
Clerk middleware does not protect routes by default; require an explicit protected-route matcher before assuming a page, API route, or tRPC endpoint is private.
Do not commit `CLERK_SECRET_KEY`, webhook signing secrets, OAuth provider secrets, or copied dashboard values to source control, issue comments, screenshots, or chat transcripts.
Review middleware matchers carefully. A broad matcher can affect static assets and public routes, while a narrow matcher can leave sensitive routes unauthenticated.
Treat organization roles, custom permissions, and metadata checks as authorization logic that needs tests, not just UI hiding.
Webhook handlers can mutate user, membership, subscription, and organization state. Make handlers idempotent and verify signatures before processing events.
Confirm production domains and redirect URLs before deploy; wrong origins can break sign-in, leak users into the wrong environment, or create confusing callback loops.
✓The download URL is Better Auth's external source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows.
Do not commit Better Auth secrets, OAuth provider secrets, database URLs, email-provider credentials, API-key plugin secrets, or copied dashboard values.
Run schema generation or migrations only against the intended database environment; auth tables, sessions, accounts, and verification records are production-critical.
Treat route protection as server-side authorization work. UI hiding, optimistic middleware redirects, or cookie existence checks are not full access control.
Review `proxy.ts` or `middleware.ts` behavior by Next.js version before relying on database-backed session checks inside request middleware.
Keep OAuth callback URLs, base URLs, trusted origins, and cookie settings environment-specific to avoid broken login loops or cross-environment session confusion.
Track Better Auth release notes and security advisories before introducing auth flows or enabling advanced plugins in production.
Add rollback steps before replacing an existing auth provider because user, account, session, and verification tables can affect active logins.
✓The download URL is Convex's external JavaScript SDK source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows.
`convex dev` logs in, creates or connects a cloud dev deployment, writes deployment URLs, and syncs backend functions; confirm the target account and project first.
Treat `convex import`, migrations, table rewrites, backfills, deletes, and scheduled functions as data-mutating operations that need environment confirmation.
Do not commit Convex deployment secrets, auth provider secrets, API keys for actions, webhook secrets, or copied dashboard values.
Keep client-exposed values such as `NEXT_PUBLIC_CONVEX_URL` separate from server-only secrets used by actions, auth providers, integrations, or external APIs.
Review generated APIs, table indexes, pagination, and query fan-out before shipping realtime screens that could overload clients or expose broad datasets.
When actions call external services or LLM APIs, add timeout, retry, logging, rate-limit, and secret-handling guidance before production use.
✓The download URL is the external `amannn/next-intl` source archive, not a HeyClaude-packaged skill archive; review source provenance before using it in automated workflows.
Locale routing can change public URLs, redirects, cache keys, static rendering behavior, metadata, sitemap output, canonical URLs, and analytics attribution.
Proxy or middleware rules can run for broad request sets. Review matchers, excluded assets, API routes, auth routes, preview mode, and static files before shipping.
Do not put secrets, unreleased product copy, private customer examples, support transcripts, or regulated data into translation messages, examples, screenshots, or AI prompts.
AI-assisted translation output needs human review for product accuracy, legal terms, accessibility labels, cultural fit, pluralization, and formatting placeholders.
TypeScript message-key augmentation can expose missing keys and route type errors at build time. Treat new type failures as content or routing defects, not noise to suppress.
Static rendering with locale params can affect build size, revalidation, and deployment time. Review generated paths, `generateStaticParams`, and fallback strategy before broad locale rollout.
Locale switchers and redirects can lock users into the wrong locale or loop if cookies, domains, prefixes, and auth redirects are not tested together.
Privacy notes
✓Clerk processes user identity, email addresses, sessions, cookies, authentication factors, OAuth profile data, organization membership, and optional user metadata.
Application logs, error reports, webhook payloads, request traces, and AI chat transcripts can retain user IDs, email addresses, session state, redirect URLs, or organization names.
Keep public examples synthetic. Do not paste real Clerk keys, dashboard screenshots, webhook payloads, user records, or organization metadata into prompts or PRs.
Review Clerk, deployment-provider, analytics, and AI-assistant retention policies before using real customer identity data in troubleshooting sessions.
If custom metadata stores roles, billing flags, internal account IDs, or entitlement data, treat it as sensitive authorization data and avoid exposing it client-side unless intended.
✓Better Auth handles user identity, email addresses, password-auth state, OAuth profile data, sessions, cookies, accounts, verification tokens, and plugin-specific user data.
Application logs, error trackers, request traces, AI prompts, and screenshots can retain user IDs, emails, callback URLs, cookies, session state, or OAuth provider details.
Use synthetic users and test OAuth applications for examples, demos, issue reports, screenshots, and AI-assisted troubleshooting.
If organization, API key, two-factor, passkey, or SSO plugins are enabled, treat membership, roles, credentials, and device metadata as sensitive authorization data.
Review Better Auth, database, deployment-provider, analytics, email-provider, and AI-assistant retention policies before using real customer identity data.
✓Convex can store user records, app data, realtime query results, auth identifiers, scheduled job state, file metadata, logs, and action inputs or outputs.
Client queries, browser traces, app logs, error trackers, screenshots, and AI prompts can expose document IDs, user IDs, table names, deployment URLs, or sampled records.
Use synthetic seed data for examples, imports, demos, issue reports, screenshots, and AI-assisted troubleshooting.
Review Convex, auth-provider, deployment-provider, analytics, external API, and AI-assistant retention policies before using real customer data.
If Convex actions call LLMs, payment systems, email providers, or webhooks, document what user data leaves Convex and where it is retained.
✓next-intl projects can process locale preferences, route locale params, locale cookies, Accept-Language headers, localized content, user-facing copy, CMS payloads, and analytics events.
Translation files, CMS exports, screenshots, prompts, pull requests, and issue reports can reveal unreleased messaging, pricing, product plans, legal text, user examples, or internal route names.
Locale detection, domain routing, redirects, and analytics can combine language preference with IP-derived geography, logged-in user identifiers, or marketing attribution.
Use synthetic content, placeholder brands, redacted examples, and non-production locales for demos, screenshots, validation, and AI-assisted troubleshooting.
Review Next.js, next-intl, translation-management, CMS, analytics, logging, hosting, and AI-assistant retention behavior before using real customer content or support text in localization workflows.
Prerequisites
Next.js App Router project or migration branch.
Clerk account and application for the target environment.
`NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY` and `CLERK_SECRET_KEY` available through local and deployment environment configuration.
Route map that separates public pages, protected app pages, API routes, and admin or organization-scoped areas.
Next.js App Router project or migration branch with a known package manager.
Database choice and adapter plan, such as Drizzle, Prisma, MongoDB, or Better Auth's built-in Kysely-backed flow.
Local, preview, staging, and production secret-management path for Better Auth secrets, OAuth client IDs, and OAuth client secrets.
Route map that separates public pages, authenticated pages, API routes, server actions, admin routes, and organization-scoped areas.
Next.js App Router project or migration branch with a known package manager.
Convex account access and permission to create or use the target Convex project and deployment.
`NEXT_PUBLIC_CONVEX_URL` and any Convex deployment environment variables managed through local, preview, staging, and production secret configuration.
Data model plan for Convex tables, indexes, generated API functions, and client query/mutation usage.
Next.js project with App Router, Pages Router, or a known migration plan; App Router should be identified explicitly before applying current next-intl setup guidance.
Locale strategy covering supported locales, default locale, locale prefixes, domain routing, fallback behavior, and whether routes should use a top-level `[locale]` segment.
Message source plan covering local JSON files, remote CMS or translation management system, namespace structure, review workflow, and missing-key behavior.
Decision for where `i18n/request.ts`, routing config, navigation helpers, and proxy or middleware files belong in the repository layout.