Most prompting advice for coding agents comes down to one idea: give the agent the same brief you'd give a sharp new teammate. That means the goal, the constraints, what "done" looks like, and what to leave alone.
Here are ten AI coding prompts for the full path from idea to production. They work with Cursor, Claude Code, Codex or any other agent that can read your repo and run commands. Copy them, fill in the [brackets], and adjust to your stack. The examples assume Next.js and Supabase, but the structure carries over to other stacks.
A tip before you start: run them in order and in separate sessions where it makes sense. A fresh context for each step keeps the agent focused and stops old assumptions from carrying over.
1. The project brief (plan before code)
I want to build [one-sentence product description] for [who it's for].
Before writing any code, produce a plan:
1. The core user flows (max 5), each as a numbered list of steps.
2. The data model: tables, key columns, and relationships.
3. Which pages/routes we need.
4. What we are explicitly NOT building in v1.
5. Open questions you need me to answer.
Stack: [Next.js + Supabase + Vercel]. Keep v1 small enough to ship in a weekend.
Do not create files yet.
The "do not create files yet" line matters. Planning and building are different jobs, and mixing them gets you code for a plan you never agreed to.
2. Write the agent's rulebook (AGENTS.md)
Create an AGENTS.md at the repo root for this project. Include:
- Setup, dev, build, test, and lint commands (read package.json; don't invent scripts).
- Code style rules you can infer from the existing code.
- Folder structure: what lives where.
- Security rules: never commit secrets, server-only keys never get a
NEXT_PUBLIC_ prefix, every new table needs Row Level Security.
- "Definition of done": build passes, tests pass, lint passes.
Keep it under 80 lines. Ask me about anything you can't infer.
AGENTS.md is an open format that many coding agents read, including Codex, Cursor, GitHub Copilot's coding agent and Gemini CLI. Writing it once saves you from repeating the same rules in every chat. Our guide to writing an AGENTS.md file covers what to put in it.
3. Schema with security built in
Using the plan we agreed on, write a SQL migration for these tables:
[list tables].
Requirements:
- Primary keys, foreign keys, created_at timestamps, sensible NOT NULLs.
- Enable Row Level Security on every table.
- Revoke default grants from anon and authenticated, then grant back only
what each role needs.
- One policy per operation (select / insert / update / delete), scoped with
`to authenticated` and `(select auth.uid())`.
- Index every column used in a policy filter.
Explain each policy in one line, then show the SQL.
Every requirement in this prompt comes from Supabase's Row Level Security guide. It warns that a table in an exposed schema without RLS "is readable and writable by any role with a grant on it", and that adding policies doesn't remove existing grants.
4. Auth flow
Add email sign-up, sign-in, and sign-out using [Supabase Auth].
- Protect every route under /app; redirect signed-out users to /login.
- Use the server client for anything that reads user data.
- Show clear error messages for wrong password, unconfirmed email, and
network failure.
- Don't build a custom password system.
List the files you'll touch before you touch them.
5. One feature, end to end
Implement this feature as one vertical slice: [feature].
User story: As a [user], I want to [action] so that [outcome].
Acceptance criteria:
- [criterion 1]
- [criterion 2]
Touch only the files needed. Add or update tests for the new behavior.
When done, run the build and tests and paste the results.
Vertical slices (UI + API + data for one feature) are much easier to review than "build the whole backend, then the whole frontend."
6. Tests that actually test something
Write tests for [file or feature]. For each function or route:
- One happy-path test.
- At least two edge cases (empty input, wrong user, missing record).
- One test proving an unauthorized user is denied.
Don't mock the thing under test. Run the tests and fix failures in the
code, not by weakening assertions. Tell me if a test reveals a real bug.
The last two lines are there because agents sometimes make a failing test pass by loosening the assertion. Saying so up front helps prevent it.
7. Debug from evidence
Bug: [what happens] instead of [what should happen].
Steps to reproduce: [steps].
Error output:
[paste the full error / stack trace / log lines]
First, explain the most likely root cause and how you'd confirm it.
Then add the smallest fix. Don't refactor unrelated code. Add a test
that fails before the fix and passes after.
8. Security review of the diff
Review the changes on this branch versus main as a security reviewer.
Check specifically for:
- Missing authorization checks (can user A read or change user B's data?).
- Tables without Row Level Security or with overly broad policies.
- Secrets in code, or server-only keys exposed to the browser
(anything secret with a NEXT_PUBLIC_ prefix).
- Unvalidated user input reaching SQL, HTML, redirects, or file paths.
- New dependencies: does each one exist, is it maintained, is it needed?
Report findings by severity with file and line. Don't change code yet.
This list follows the top of the OWASP Top 10:2025: Broken Access Control is #1, followed by Security Misconfiguration and Software Supply Chain Failures. The browser-exposure check comes from how Next.js works: NEXT_PUBLIC_ variables are inlined into the JavaScript sent to the browser. On the Supabase side, secret keys bypass Row Level Security and must never ship to the client. Before launch, run through our vibe coding security checklist.
9. Pre-launch checklist
We're about to deploy to production. Produce a launch checklist for this
repo and check off what you can verify yourself:
- Required environment variables (names only) for Production and Preview.
- Build passes with production settings.
- Error pages (404, 500) exist and don't leak stack traces.
- Auth redirect URLs configured for the production domain.
- Database migrations applied, RLS enabled on every table.
- Basic SEO: titles, meta descriptions, Open Graph image.
Mark each item VERIFIED, NEEDS HUMAN, or MISSING.
"NEEDS HUMAN" is the important label. Some checks, like your DNS settings or your payment provider's dashboard, are outside the agent's reach, and you want it to say so instead of guessing.
10. Clean up before it sprawls
Do a cleanup pass with zero behavior changes:
- Remove dead code and unused dependencies.
- Consolidate duplicated helpers.
- Make naming consistent with AGENTS.md.
Do it as a series of small commits, each with a clear message.
Run build and tests after each step and stop if anything fails.
How to get more out of these AI coding prompts
- Turn your favorites into skills. If you paste prompt #8 every week, save it as a skill and your agent will load it when you ask for a security review. See our guide to writing agent skills.
- Always ask for evidence. "Run the tests and paste the results" beats "make sure it works."
- Scope every prompt. "Touch only the files needed" and "don't refactor unrelated code" stop runaway diffs.
- Read the diff anyway. The prompts lower the risk, but they don't remove it. See our checklist for reviewing AI-generated code.
Keep reading
- All ten prompts in one file: the ship-a-web-app prompt pack
- How to vibe code a SaaS with Supabase and Vercel in a weekend
- How to run coding agents safely: permissions, sandboxes and secrets
FAQ
Do these prompts work with any coding agent?
Yes. They are plain-text briefs, so they work in Cursor, Claude Code, Codex or any agent that can read your repo and run commands. The examples assume Next.js and Supabase.
Why run each prompt in a separate session?
A fresh session keeps the agent focused on one step and stops assumptions from an earlier step from carrying over into the next one.
What makes a good prompt for a coding agent?
A good prompt states the goal, the constraints, what done looks like and what to leave alone, and asks the agent to show evidence such as test output.
Should I turn prompts into agent skills?
If you paste the same prompt every week, yes. A skill loads when a task matches its description, so you stop repeating yourself.