Login & Signup – Implementing Authentication

Time to build the auth experience you designed. You'll use Clerk for sign-in and store each user's data in Neon, scoped so people only ever see their own. You're on your auth branch, so everything here is tested on a preview before it reaches your live site.

Let the Clerk skill carry the details

Auth has a lot of fiddly parts. You'll install the Clerk skill so Claude already knows the current, secure way to wire Clerk into Next.js – middleware, components, session handling. You describe what you want; the skill handles the wiring.

1. Install the Clerk skill

Ask Claude in the chat: "install the clerk-setup skill" – it runs npx skills add clerk-setup for you.

Start a new chat so the skill loads

The desktop app picks up a new skill when a session starts. After installing, start a new chat – and hand it your context (your concept, that you're on the auth branch, and that you'll build Clerk + Neon auth) before you build.

Outcome: Claude has the Clerk skill and your context for the build.

I installed the Clerk skill and handed over context

2. Set up Clerk and build sign-in / sign-up

Now build the core auth. Plan it briefly, then let Claude build – it'll create your Clerk app, store the keys in the Vercel vault, add the sign-in/sign-up pages, and protect your routes.

Build Clerk auth
Using the Clerk skill, set up authentication for my app:
1.Create my Clerk application and store its keys in the Vercel vault (vercel env add … then vercel env pull) – never pasted into a file.
2.Add sign-in and sign-up pages using Clerk's components, plus a user button in the header.
3.Protect my app routes so only signed-in users can reach them (in Next.js this is the proxy file – the skill knows where it goes), while keeping public pages public.
Then show me the signup and login working in the preview.

Outcome: Users can sign up, log in, and only signed-in users can reach the app.

Sign-in, sign-up, and protected routes work

3. Add onboarding

Give new users a warm, skippable 3-screen onboarding; returning users skip it automatically.

Build the onboarding flow
Build a 3-screen, skippable onboarding that shows after a user's first signup and explains my app's value, with progress indicators and a skip option. Returning users should go straight to the app. Use Clerk to remember whether a user has completed onboarding. Show me all three screens in the preview.

Outcome: New users get a welcoming onboarding; returning users skip straight in.

My 3-screen onboarding works

4. Store and scope user data in Neon

This is the secure heart of it: keep each user's data in Neon, tied to their Clerk account, and make sure the server only ever returns the logged-in user's rows. There's no magic row-level security here – you enforce it on the server, which the Clerk skill does correctly.

Connect user data to Neon, scoped per user
Wire my user data to Neon, scoped to the logged-in user:
1.When a user signs in for the first time, create a record for them in Neon keyed to their Clerk user id.
2.For every read and write of a user's data, verify the Clerk session on the server (auth()) and filter the query by that user's id – so one user can never see or change another's data.
3.Keep all of this in Server Actions / route handlers (never client-side), and test that User A cannot see User B's data.

Outcome: Each user's data lives in Neon and is locked to them, enforced server-side.

User data is stored in Neon and scoped per user

5. Test on your preview

Push your branch so Vercel builds a preview, then run the full flow there before merging.

Test auth on the preview
Push my auth branch so Vercel creates a preview deployment, and give me the preview URL. Then walk me through testing on it:
- sign up a new user → onboarding → app,
- log in as a returning user → straight to the app,
- create some data, then sign in as a second user and confirm they can't see the first user's data,
- check the error states (wrong password, existing email).
Fix anything that's off, and let me know when it's solid.

Outcome: Your full auth flow works on the preview, including data isolation – ready to ship to production in the next lesson.

I tested the full auth flow on my preview