PRD for Cursor: structure requirements to ship exactly what you want

This page shows founders and PMs exactly how to write a PRD for Cursor, the AI-first codebase editor. You'll learn how to include a file tree, map requirements to files, and break work into actionable tasks Cursor understands. There's a real filled PRD example, specific tool comparisons, and practical tips to avoid ambiguity when designing with Cursor, Vercel, Next.js, and more.

What this is

A PRD for Cursor is a product requirements document tailored for implementation by Cursor, the AI-powered codebase editor. Unlike generic PRDs, it specifies the expected file structure, directly maps features or modules to files (e.g., Next.js page components, Supabase configs), and breaks complex specs into sequential tasks Cursor can execute one at a time. This structure prevents ambiguity and errors typical when using AI code tools like Cursor, Claude Code, or Replit. When using frameworks like Next.js and deployment platforms such as Vercel, clarity in file-tree and module mapping is essential to ship the right product, on time and to spec.

Compared to alternatives

Option	Best for	Trade-off
Cursor	AI-first teams who want to automate repo and feature scaffolds with file-level control	Requires highly structured specs; less suitable for loosely-defined projects
Lovable	Teams aiming for user research and iterative validation early	Heavier docs; slower from idea to first code
Replit	Single-file quick prototypes and hackathons	Not ideal for complex file structures or production apps
Claude Code	Conversational code refinement and inline editing	Less efficient for full project scaffold; limited by context window
v0	AI-generated UI mocks and front-end code snippets	UI focused, needs back-end integration elsewhere
Traditional PRD (Word/Docs)	Stakeholder alignment, high-level requirements across teams	Ambiguous for AI dev tools; rarely specifies code structure
Next.js	Web apps needing SSR, static export, or scalable routing (matches Cursor's strengths)	Still requires file map to avoid Cursor confusion

A real example

Filled example

A real, ready-to-customize version

Product Requirements Document: Minimalist Habit Tracker (for Cursor)

Goal: Launch a web app that lets users log daily habits, view streaks, and track metrics. Built with Next.js, Supabase, and deployed via Vercel.

Expected File Tree

/
  README.md
  package.json
  /pages
    index.tsx           // Home page: show habits, today's status
    add-habit.tsx       // Form: add new habit
    stats.tsx           // Page: streak and stats view
  /components
    HabitList.tsx       // Renders all habits, marks complete
    AddHabitForm.tsx    // Component for new habits
    StreakCounter.tsx   // Visual streak tracker
  /lib
    supabaseClient.ts   // API wrapper for Supabase
  /styles
    globals.css         // Basic styles
  .env.local            // Supabase keys

Key Functional Requirements (Mapped)

Add habit (add-habit.tsx, AddHabitForm.tsx):
- User can enter habit name, description
- Form validation (min 3 chars, max 30)
List all habits (index.tsx, HabitList.tsx, supabaseClient.ts):
- Main page shows all habits, sortable
- Pulls from Supabase table habits
Mark habit complete for today (HabitList.tsx):
- Checkbox toggles for today's status, updates Supabase completions table
View streak/stats (stats.tsx, StreakCounter.tsx):
- Pulls streak from completions, displays count and highest streak
Onboarding (index.tsx):
- Show explainer for first-time users (localStorage flag)

Ordered Tasks for Cursor

Scaffold Next.js app, set up Vercel deploy config
Set up Supabase tables: habits (id, user_id, name), completions (habit_id, date)
Implement /pages/index.tsx and HabitList.tsx for main dashboard
Build /pages/add-habit.tsx and AddHabitForm.tsx with validations
Wire up Supabase logic in /lib/supabaseClient.ts
Implement /pages/stats.tsx and StreakCounter.tsx for visual stats
Basic CSS in /styles/globals.css
Add explanatory onboarding modal

Success Metrics

Deployed to Vercel within 3 days
User can add, mark, and track at least 3 habits end-to-end
80% test coverage on all core logic

How to use this

List the product's main goals, tools, and metrics up top.: State in 1-2 lines what the product does, which frameworks/tools you want (ex: Next.js, Supabase, Vercel), and what success looks like (ex: MVP shipped in 1 week, 90% test coverage).
Map requirements to modules or files explicitly.: For every feature, specify which file, API route, or component will own it. Cursor can only build what you define—be concrete (e.g., add task in /components/NewTask.tsx, not 'add-tasks feature').
Write out the expected file tree, including stubs.: Show a complete file/folder structure up top. This removes guesswork and helps Cursor set up the repo accurately. Include files like .env, README.md, and all key pages/components.
Break every requirement into atomic, ordered tasks.: List the build steps one per line, in the order you'd like Cursor to execute. Each should produce a committable chunk—'Implement login form in /pages/login.tsx', not 'build authentication'.
Define data structures and API endpoints up front.: If you use databases (e.g., Supabase) or external APIs (like Stripe), declare each table, field, and endpoint with types early in the PRD. Cursor works better with specifics.
Finish with your success checklist and test criteria.: Close with clear, measurable acceptance: what workflows must work, what coverage to hit, and where to deploy (Vercel, self-host, etc). This makes handoff to Cursor or any dev clear.

FAQ

How specific does my file tree need to be for Cursor?

The file tree should include every top-level route, shared component, utility, and config file you expect Cursor to generate or touch—leaving stubs if needed. Cursor performs best when given explicit structure, avoiding missed files or misnamed modules.

Can I use the same PRD format for both Cursor and Claude Code?

There's overlap, but PRDs for Cursor should be even more concrete about the codebase layout and tasks. Claude Code tolerates conversational specs, but Cursor excels when you list atomic tasks and a clear file mapping.

What frameworks pair best with Cursor for fast shipping?

Next.js (for web), Supabase (for backend), and Vercel (for deploy) are ideal because they have strong boilerplate support and clear directory conventions. Cursor can recognize and scaffold these quickly, letting you iterate 10x faster than in unstructured stacks.

How do I prevent Cursor from misunderstanding my requirements?

State intent for each feature, reference specific files, and break specs into stepwise tasks. If in doubt, add a comment or line describing edge cases. Ambiguity is the enemy—Cursor won't infer missing context as a human would.