PRD Workflow in Cursor

Your PM drops a Slack message: “We need a notification system. Email, push, SMS. User preferences. Delivery tracking. Can you scope it?” You open Cursor and start typing code. Three hours later, you have half an email service, no tests, and a growing realization that you never thought through how SMS delivery confirmations would work. The PRD-to-Plan-to-Todo workflow exists to prevent exactly this. It forces you to think before you code, and it uses Cursor’s Plan mode to make that thinking fast and structured.

Note

For the full deep-dive into this methodology across all tools, see our Complete PRD-Plan-Todo Guide. This article focuses on the Cursor-specific setup and keyboard shortcuts.

What You’ll Walk Away With

• A repeatable 3-phase workflow: PRD, then Plan, then Todo — each using a different Cursor mode
• Cursor-specific shortcuts for switching between Plan mode and Agent mode at the right moments
• A PRD template you can paste into any new feature conversation
• The ability to save plans to .cursor/plans/ for team reference and future context

Phase 1: Write the PRD in Agent Chat

The PRD does not need to be a 20-page document. It needs to be specific enough that you (and the AI) agree on what “done” looks like before any code gets written.

Open Agent mode (Cmd+I) and start by asking the AI to help you draft the requirements.

Copy-paste prompt to generate a PRD

I need to build a user notification system with the following capabilities:
- Email notifications via SendGrid
- Push notifications via Firebase Cloud Messaging
- SMS via Twilio
- User preference management (which channels are enabled per notification type)
- Delivery status tracking with webhook callbacks

Help me write a PRD for this feature. Include:
1. User stories
2. Functional requirements with acceptance criteria
3. Non-functional requirements (performance, security, scalability)
4. Edge cases and error scenarios
5. Out of scope items

Ask me clarifying questions before drafting if anything is ambiguous.

The key instruction at the end — “Ask me clarifying questions” — prevents the AI from making assumptions. It will ask about your existing infrastructure, authentication model, database setup, and volume expectations. Answer these questions. Every answer you provide here is context the AI uses to generate better code later.

PRD Quality Checklist

Before moving to Phase 2, make sure your PRD includes:

• Specific acceptance criteria, not vague goals. “Users can toggle email/SMS/push per notification type” not “users manage preferences”
• Error scenarios. What happens when SendGrid is down? When a phone number is invalid?
• Non-functional requirements. How many notifications per second? What is the acceptable delivery latency?
• Out of scope. Explicitly stating what you are not building prevents scope creep during implementation

Phase 2: Plan with Plan Mode

Now switch from Agent mode to Plan mode. Press Shift+Tab in the agent input to toggle to Plan mode. Cursor also auto-suggests Plan mode when it detects complex tasks.

In Plan mode, the agent will:

1. Research your codebase to understand existing patterns
2. Ask clarifying questions about implementation details
3. Generate a detailed technical plan
4. Wait for your approval before writing any code

Copy-paste prompt to generate an implementation plan

Based on the notification system PRD we just created, generate a detailed
technical implementation plan. Include:

1. Database schema design (what tables, columns, indexes)
2. API endpoint design (routes, request/response shapes, validation)
3. Service architecture (which services, how they communicate)
4. Background job design (workers, queues, retry logic)
5. Frontend component breakdown (if applicable)
6. Implementation order with dependencies between tasks
7. Testing strategy for each component

Reference existing patterns in this codebase where relevant.

Save the Plan

Once the plan looks right, save it to your workspace. Click “Save to workspace” in the plan output. This stores the plan in .cursor/plans/, which serves two purposes:

1. Team documentation — other developers can read the plan before reviewing your PR
2. Future context — you can reference the plan with @ in later conversations if you need to resume work

Iterate the Plan Before Building

This is the most underused step. Review the plan critically:

• Does the implementation order make sense? Can you start the frontend before the API is ready, or is there a hard dependency?
• Are there simpler alternatives the AI missed?
• Does the plan align with your existing architecture, or is it introducing new patterns unnecessarily?

Edit the plan in chat. Tell the agent what to change. Only move to Phase 3 when the plan is something you would confidently hand to a colleague.

Note

Spending 15 minutes refining a plan saves hours of rework during implementation. The hard part is figuring out what to build — once the plan is solid, the AI handles the implementation efficiently.

Phase 3: Build from the Todo List

Switch back to Agent mode (press Shift+Tab or select from the mode picker with Cmd+.). Now work through the plan systematically.

1. Ask the agent to create a todo list from the plan

   Convert the implementation plan into a markdown todo list with checkboxes.
   Group tasks by phase. Each task should be completable in 1-4 hours.
   Include acceptance criteria for each task.

2. Start with the first task

   Let's implement the first task: Create database migrations for the
   notification tables. Follow our existing migration patterns in src/db/migrations/.

3. Verify before moving on

   Run the migration and show me the resulting schema.
   Then run our existing tests to make sure nothing is broken.

4. Commit at milestones

   After completing each phase, commit your changes. Cursor creates checkpoints automatically, but git commits give you a named, shareable restoration point.

5. Reference the plan for context

   If the agent loses track of the bigger picture in a long conversation, start a new chat and reference the plan:

   @.cursor/plans/notification-system.md
   We've completed phases 1 and 2. Let's start phase 3: implementing the
   delivery workers. Begin with the EmailWorker.

Using Checkpoints for Safety

Cursor creates a checkpoint before every set of changes the agent makes. If a task goes off the rails:

1. Press Escape to stop the agent mid-execution
2. Click the Restore button next to the checkpoint in the conversation
3. Refine your prompt and try again

This is faster than manually reverting files. Use it aggressively — there is no penalty for restoring a checkpoint.

The Workflow in Practice

Here is what a real session looks like, compressed:

[Plan Mode] "I need to add Stripe webhook handling for subscription events.
Our existing payment code is in src/services/billing/. Generate a plan."

[Plan Mode] Agent asks: "Do you want idempotent webhook handling?
Do you already have a webhook_logs table?"

[Plan Mode] You answer: "Yes to idempotent handling. No webhook_logs
table yet -- include that in the plan."

[Plan Mode] Agent generates plan with 4 phases, 12 tasks.

You review, adjust the order of two tasks, approve.

[Agent Mode] "Start with task 1: create the webhook_logs migration."
Agent creates migration, runs it, shows schema.

[Agent Mode] "Task 2: create the webhook endpoint with signature verification."
Agent implements, writes tests, runs them. Two tests fail.
Agent fixes implementation, reruns. All green.

[Agent Mode] Repeat for remaining tasks...

Copy-paste prompt for a quick PRD-to-build session

I need to add [feature description]. Before writing any code:

1. Ask me 3-5 clarifying questions about requirements
2. Once I answer, create a brief PRD with acceptance criteria
3. Generate a technical implementation plan
4. Break the plan into a todo list

Then implement each task one at a time, running tests after each.
Commit checkpoints between phases.

When This Breaks

The plan is too generic: This usually means your PRD lacked specifics. Go back to Phase 1 and add concrete acceptance criteria, technology choices, and constraints.

The agent diverges from the plan during implementation: Start a new chat, reference the plan with @, and give it a specific task from the todo list. Long conversations cause drift — short, focused conversations with explicit context produce better results.

The plan does not fit your architecture: The agent can only match patterns it has seen. If your architecture is unusual, add a project rule describing it (see Project Rules) and regenerate the plan.

Tasks take longer than estimated: The todo list is a guide, not a contract. If a task is larger than expected, ask the agent to break it into sub-tasks.

What’s Next

MCP Setup Connect Cursor to your database, browser, GitHub, and external APIs using Model Context Protocol servers.