Guide · Cursor and Claude Code · Checked against Cursor and Claude Code's docs, October 2026 · Updated October 11, 2026

The Cursor and Claude Code launch checklist

Coding agents write real code in a real repo, which means nothing is set up for you: no built-in backend, no automatic security scan. Here are the ten things to check before real people use what you built, a prompt to give the agent for each, and the review tools both editors already include.

Your backend is Supabase? Pair this with the Supabase launch checklist.

1. 01

   Your data

   Your schema and migrations

   With a coding agent, your data model lives in code: migrations, schema files, ORM models. If you never described how things relate, the agent guessed, and every later feature builds on that guess. Read the schema the way you'd read a floor plan.

   Ask the agent

   Read this project's schema and migrations and describe the data model in plain English: every table, what it stores, and how the tables connect. Flag anything you assumed instead of being told, and anything stored twice.

   Copy prompt
2. 02

   Accounts

   Your auth provider

   Accounts are a lifecycle, not a sign-up screen: sign up, confirm, sign in, reset a forgotten password, sign out, and delete the account and its data. Agents build the first two and forget the rest unless you ask.

   Ask the agent

   List every account flow in this codebase: sign up, email confirmation, sign in, forgot password, sign out and delete account. For each, show me the code or say it's missing. Account deletion must remove the user's data on the server.

   Copy prompt
3. 03

   Permissions

   Server code and database policies

   A hidden button isn't a lock. Anyone can skip your screens and call your server or database directly, so every check about who can see or change something has to run on the server.

   This happened to me: one of my apps kept people out of private groups only by hiding the button. The data was one direct request away until I asked where the server actually checked membership.

   Ask the agent

   For every piece of private data and every admin action, show me the exact server-side check (database policy, API middleware or function) that enforces it. List anything only protected by hiding it in the UI.

   Copy prompt
4. 04

   Database rules

   Supabase RLS, Firebase rules, or your API

   If your front end talks to the database directly (Supabase, Firebase), the database's access rules are the only thing between strangers and your users' data. If it goes through your own API, every endpoint needs its own authorization check.

   Ask the agent

   Does the front end talk to the database directly or through an API? If directly, list every table with its access rules in plain English. If through an API, list every endpoint and the authorization check it runs. Flag anything reachable without signing in.

   Copy prompt
5. 05

   Secret keys

   .env files and your host's environment variables

   Secrets belong in server-side environment variables, never in front-end code or a public repo. Watch build-tool prefixes: Vite builds anything named VITE_… into the code browsers download. Also keep your .env files away from the agent itself (see below), and replace any secret that was ever committed.

   Ask the agent

   Search this repo, including git history if you can, for API keys, tokens and passwords. For each, give me its name (not its value), whether it's secret, and whether it's in front-end code, a VITE_ or NEXT_PUBLIC_ variable, or a commit. Tell me which ones I need to rotate.

   Copy prompt
6. 06

   When things break

   Error handling and retries

   Agents write the happy path. Ask what happens when an action fails halfway, like a payment that goes through when the order doesn't save, and make retries safe so a second tap doesn't create a duplicate.

   Ask the agent

   For each important action (sign up, save, pay, upload, send), trace what happens if it fails halfway or the network drops. Show me what the person sees, and make retries idempotent so they can't duplicate data or charges.

   Copy prompt
7. 07

   What leaves your app

   Emails, push, payments, webhooks

   Anything that leaves your system fires immediately and can't be deleted afterward. That includes what your tests trigger: cleaning up the database proves the database is clean, not that nobody was notified.

   This happened to me: my automated tests cleaned up the database perfectly, and had already sent push notifications to real people's phones. The fix was a rule at the sending boundary that ignores anything marked as a test.

   Ask the agent

   List every place this code sends something outside the system: emails, push notifications, texts, payments, webhooks. For each, what triggers it, and does anything in our tests or scripts trigger it against real people? Add a guard so test data can never send.

   Copy prompt
8. 08

   Uploads

   Your storage bucket rules

   Uploaded files usually live in a separate storage service with its own access rules. Files in a public bucket can be opened by anyone with the link. Keep private files private and set size and file-type limits on the server.

   Ask the agent

   Where are uploaded files stored, is each bucket public or private, who can open a file if they have its link, and where are size and file-type limits enforced? Make private files private.

   Copy prompt
9. 09

   Hosting and cost

   Your host's billing and usage pages

   Speed and cost live on real machines. A small or free plan can throttle you, pause your project, or bill you for something you thought you stopped. Know what runs where and what it costs before a launch brings a spike.

   This happened to me: my app once took 15 to 30 seconds to load messages while the database answered in 79 milliseconds. The server had run out of borrowed processing power, and upgrading my plan didn't upgrade the machine.

   Ask the agent

   List every service this project depends on (hosting, database, storage, email, AI APIs). For each: plan, monthly cost at current usage, limits, and what happens when I hit them. What breaks first at ten times the traffic?

   Copy prompt
10. 10

    Knowing when it breaks

    Error tracking and uptime checks

    Check the thing that matters. An alert that only checks whether the server is on will stay green while the product is broken. Test what a real user does, and track keys and domains that expire.

    This happened to me: on one side project, my alert only checked that the server was running. The product was dead for three weeks before anyone noticed.

    Ask the agent

    How would I find out right now if this app stopped working for users? Add error tracking and a daily check that performs a real user action, and list every key, certificate and domain with its expiry date.

    Copy prompt

Before you ship

1. Claude Code: run /security-review. It's built in, and runs an on-demand security pass over the changes on your current branch. For every pull request, Anthropic publishes a free GitHub Action (anthropics/claude-code-security-review) that comments on security issues inline.
2. Claude Code: keep secrets out of its reach. Add deny rules such as "Read(./.env)" and "Read(./.env.*)" to permissions in .claude/settings.json, review commands before you approve them, and audit your rules with /permissions.
3. Cursor: turn on PR review. Bugbot reviews pull requests for bugs and security issues, and Cursor's Security Reviewer checks pull requests for vulnerabilities before you merge.
4. Cursor: add a .cursorignore, and don't rely on it alone. List **/.env, **/.env.* and key files in it. Cursor's own docs say it isn't a security boundary, since terminal commands and MCP tools can still read ignored files. Keep the default command approvals on; auto-run modes are best-effort guardrails.
5. Either tool: write your rules down. Put your security rules in the agent's rules file (CLAUDE.md or Cursor Rules), like "every table gets access rules" or "secrets only in server code," so every session starts with them. Rules guide the agent; reviews still catch what slips through.

Common questions

Sources

• Claude Code: Security
• Claude Code: Settings (permission rules)
• Anthropic: claude-code-security-review GitHub Action
• Cursor: Agent security
• Cursor: Ignore file
• Cursor: Bugbot
• Cursor: Security Agents

An independent guide, not affiliated with Cursor and Claude Code, and not a professional security audit. Dashboards change often; if a menu has moved, the prompts still work. Written by Andrew Adams, based on the Vibe Coding Checklist. Other guides: Lovable · Bolt · Cursor and Claude Code · Supabase · Firebase.