The PRD→Plan→Todo Methodology

The PRD→Plan→Todo methodology is a systematic approach to AI-assisted development that transforms high-level requirements into working code through three distinct phases. This workflow has become the gold standard for teams using Claude Code and Cursor.

The Three Pillars

1. PRD (Product Requirements Document): What needs to be built
2. Plan: How to build it (technical approach)
3. Todo: Specific implementation tasks

Why This Methodology Works

Traditional development often jumps directly from requirements to code, leading to:

• Misaligned implementations
• Forgotten edge cases
• Technical debt from poor planning
• Difficult code reviews

The PRD→Plan→Todo approach ensures:

• Clear alignment between business needs and technical implementation
• Comprehensive coverage of all requirements
• A systematic structure that the AI can follow consistently
• Built-in documentation for future maintenance

Phase 1: PRD (Product Requirements Document)

The PRD defines what needs to be built from a business perspective.

Creating Effective PRDs

Structure

# Feature: User Authentication System

## Overview
Brief description of the feature and its business value

## User Stories
As a [user type], I want to [action] so that [benefit]

## Functional Requirements
1. Users can register with email/password
2. Email verification required
3. Password reset functionality
4. Remember me option

## Non-Functional Requirements
- Response time < 200ms
- Support 10k concurrent users
- GDPR compliant
- Accessibility WCAG 2.1 AA

## Acceptance Criteria
- ☐ User can successfully register
- ☐ Invalid emails are rejected
- ☐ Passwords meet security requirements
- ☐ Session persists with "remember me"

## Out of Scope
- Social login (Phase 2)
- Two-factor authentication (Phase 2)

AI Prompt

Tip

Copy-paste prompt for generating a PRD:

Generate a PRD for a passwordless email-and-magic-link login feature. Include: an overview with business value, user stories for end users and admins, a numbered list of functional requirements, non-functional requirements (performance, security, GDPR compliance), testable acceptance criteria, an explicit out-of-scope list, UI/UX requirements, and the integration points with our existing user service. Ask me about anything ambiguous before finalizing.

Swap the feature description for your own, but keep it concrete. A vague “generate a PRD for auth” produces a vague PRD.

Best Practices

• Be specific: “User sees error message” → “User sees ‘Email already exists’ error in red below email field”
• Include examples: Show sample inputs/outputs
• Define edge cases: What happens when things go wrong?
• Set measurable criteria: Use numbers for performance requirements
• Consider all users: Include admin, regular users, guests
• Version control: Track PRD changes over time

Real-World PRD Example

E-commerce Checkout Feature

# PRD: Express Checkout Feature

## Overview
Implement one-click checkout for returning customers to reduce cart abandonment by 25%

## User Stories
1. As a returning customer, I want to complete purchase with one click
2. As a new customer, I want the option to save my details for future
3. As an admin, I want to track express checkout usage

## Functional Requirements
1. Store encrypted payment methods (PCI compliant)
2. Pre-fill shipping address from last order
3. Show order summary before confirmation
4. Send email receipt immediately
5. Update inventory in real-time

## Performance Requirements
- Checkout completion < 3 seconds
- Support 1000 concurrent checkouts
- 99.9% uptime during business hours

Phase 2: Technical Plan

The Plan translates business requirements into technical architecture and approach.

Creating Comprehensive Plans

Start by turning the PRD into a plan, then drill into components and risks.

Tip

Copy-paste prompt for generating a technical plan:

Based on this PRD, create a technical plan. Include: a high-level architecture overview, technology choices with a one-line justification each, the data model design, the API endpoints needed, security considerations, integration points with existing systems, and a deployment strategy. Do not write implementation code yet, this is a plan for me to review.

Then push the AI to decompose the architecture and surface risks:

Break down the architecture into:
- Frontend components/pages needed
- Backend services/modules
- Database schema changes
- External service integrations
- Infrastructure requirements

Then list the technical risks and how we mitigate each one
(performance bottlenecks, security vulnerabilities, scalability
limits, third-party dependencies).

Plan Template

Backend Plan

# Technical Plan: User Authentication

## Architecture Overview
- JWT-based stateless authentication
- PostgreSQL for user data
- Redis for session management
- Email service for notifications

## API Design
POST /api/auth/register
POST /api/auth/login
POST /api/auth/logout
POST /api/auth/refresh
POST /api/auth/reset-password

## Database Schema
users:
- id (uuid, primary key)
- email (unique, indexed)
- password_hash
- email_verified (boolean)
- created_at, updated_at

sessions:
- token (primary key)
- user_id (foreign key)
- expires_at
- ip_address

## Security Measures
- Bcrypt for password hashing (12 rounds)
- Rate limiting on auth endpoints
- CORS properly configured
- Input validation on all fields

Frontend Plan

# Frontend Technical Plan

## Component Architecture
- AuthProvider (context for auth state)
- LoginForm component
- RegisterForm component
- PasswordResetFlow
- AuthGuard HOC for protected routes

## State Management
- useAuth hook for auth operations
- Local storage for token persistence
- Session storage for temporary data

## UI/UX Flow
1. Modal-based auth forms
2. Real-time validation
3. Loading states during API calls
4. Success/error notifications
5. Redirect after login

## Performance
- Lazy load auth components
- Prefetch auth check on app load
- Optimistic UI updates

Phase 3: Todo List (Implementation Tasks)

The Todo list breaks the plan into specific, actionable tasks that can be implemented.

Generating Effective Todos

Tip

Copy-paste prompt for breaking a plan into todos:

Convert this technical plan into a detailed todo list. Each task must be completable in 1 to 4 hours, grouped by component or feature area, with explicit dependencies, a P0/P1/P2 priority, and a clear acceptance criterion. Include a testing task for every component and a documentation task at the end. Output it as a Markdown checklist.

Todo List Example

Structured Format

# Implementation Todos: User Authentication

## Database Setup (P0)
- ☐ Create database migrations for users table
- ☐ Create database migrations for sessions table
- ☐ Add indexes for email and token lookups
- ☐ Seed database with test users

## Backend API (P0)
- ☐ Implement password hashing utility
- ☐ Create POST /api/auth/register endpoint
  - Input validation
  - Email uniqueness check
  - Send verification email
- ☐ Create POST /api/auth/login endpoint
  - Validate credentials
  - Generate JWT token
  - Create session record
- ☐ Add rate limiting middleware
- ☐ Write API integration tests

## Frontend Components (P1)
- ☐ Create AuthContext and Provider
- ☐ Implement useAuth hook
- ☐ Build LoginForm component
  - Form validation
  - Error handling
  - Loading states
- ☐ Build RegisterForm component
- ☐ Add AuthGuard HOC
- ☐ Write component tests

## Integration (P1)
- ☐ Connect frontend to backend API
- ☐ Implement token refresh logic
- ☐ Add error interceptors
- ☐ Test full auth flow

## Documentation (P2)
- ☐ Document API endpoints
- ☐ Create auth flow diagram
- ☐ Write deployment guide

AI-Friendly Format

## Todo: Implement User Registration

**Task**: Create user registration endpoint
**Acceptance Criteria**:
- Validates email format
- Checks email uniqueness
- Hashes password with bcrypt
- Sends verification email
- Returns appropriate errors

**Dependencies**: Database migrations complete
**Priority**: P0
**Estimated Time**: 2 hours

**Implementation Notes**:
- Use Joi for validation
- Return 409 for duplicate email
- Log registration attempts

Executing with AI Assistance

The PRD to Plan to Todo flow is identical in spirit across all three tools: feed in the PRD, plan read-only, then implement one todo at a time. What differs is how each tool ingests context and gates its edits.

Cursor

Reference the PRD with @docs/auth-prd.md, switch the Agent to Plan mode to review the approach, then accept to implement. Your conventions live in .cursor/rules (the modern replacement for .cursorrules).

Read @docs/auth-prd.md. In Plan mode, propose the technical
plan and the file changes for the database schema and the
register/login endpoints. Follow the conventions in
.cursor/rules. I'll review the plan before you apply edits.

Then work the todo list with focused follow-ups, accepting each diff before moving on.

Claude Code

Run claude in your project directory and feed it the PRD. Use /plan so it plans read-only before touching files; Claude tracks the resulting todos in-session and works them one at a time.

Read the requirements in @docs/auth-prd.md, then enter plan
mode and produce a technical plan. Once I approve it, convert
it into a todo list, track those todos, and implement them one
at a time, pausing after each for review.

For deeper reasoning during planning, raise the effort level in /model rather than typing “think harder” (thinking keywords no longer allocate a budget).

Codex

Put durable project context in AGENTS.md at the repo root so every session loads your conventions. Launch codex, toggle /plan-mode (or start with codex --sandbox read-only) to plan without edits, and run /review on the diff before you stage anything.

Read @docs/auth-prd.md and the conventions in AGENTS.md. In
plan mode, produce the technical plan and a dependency-ordered
todo list. After I approve, implement the first task only, then
stop so I can /review the diff.

The streamed plan shows each step as pending, in-progress, or completed, so you can watch Codex march down the list.

Advanced Patterns

Iterative Refinement

The Feedback Loop

graph LR A[PRD] --> B[Plan] B --> C[Todo] C --> D[Implementation] D --> E[Testing] E --> F[Feedback] F --> A

After implementation, update your documents:

• PRD: Add discovered requirements
• Plan: Document architectural decisions
• Todo: Mark completed, add new tasks

Team Collaboration

Shared Documents

• Store PRDs in /docs/requirements/
• Keep plans in /docs/architecture/
• Track todos in /docs/tasks/ or project management tool

AI Context Sharing

• Reference documents with @docs/requirements/auth-prd.md
• Include team decisions in prompts
• Use consistent terminology across team

Integration with Existing Workflows

Agile/Scrum

• PRD: Created during sprint planning
• Plan: Technical refinement meeting
• Todo: Becomes sprint backlog items
• Each todo can map to a story point

Kanban

• PRD: Enters backlog when approved
• Plan: Created when pulled to “Analysis”
• Todo: Individual cards on board
• Flow: Backlog → Analysis → Dev → Review → Done

Waterfall

• PRD: Part of requirements phase
• Plan: Design phase output
• Todo: Development phase checklist
• Each phase formally reviewed

When This Breaks

The methodology fails in predictable ways once you run it on real features. Here are the failure modes and the recovery prompts that pull you back on track.

Caution

The AI drifts from the plan mid-implementation. Three todos in, the model starts inventing structure the plan never described. Re-anchor it to the approved plan and the specific task.

You have started deviating from the approved plan. Re-read the plan and the current todo, then implement ONLY the current task as planned. List any place where the plan turned out to be wrong, but do not change course without my sign-off.

Caution

Todos balloon past four hours. A task you thought was small keeps expanding. That is a sign the plan under-specified it. Split it before sinking more time in.

The current task is larger than estimated. Stop implementing and instead break it into sub-tasks of under two hours each, each with its own acceptance criterion. We will re-prioritize before continuing.

Caution

The plan contradicts the existing architecture. The proposed approach duplicates a service or violates a contract that already exists in the codebase. Force a reconciliation against the real files.

The plan introduces a new pattern that conflicts with our existing code in @src/services/. Identify the conflict, then revise the plan to reuse what already exists. Flag anything that genuinely cannot be reused and explain why.

Caution

You skipped the plan and went straight from PRD to todos. Even for small features, generate at least a brief technical plan first, it gives the AI architectural context and prevents inconsistent implementations across tasks.

Measuring Success

Track these metrics to improve your process:

1. Completion Rate: percentage of todos completed as originally written
2. Rework Rate: how often implemented features need changes
3. Time Accuracy: actual versus estimated time for todos
4. Requirement Coverage: percentage of PRD requirements successfully implemented
5. Documentation Quality: post-implementation documentation completeness

Teams that adopt a plan-first workflow generally report faster delivery and fewer regressions on large migrations, largely because the planning phase surfaces edge cases before any code is written, rather than during a painful review.

Two More Prompts Worth Keeping

Use these to harden a plan and to sequence the work once the todos exist.

Tip

Copy-paste prompt for auditing a plan before you commit to it:

Review this technical plan and identify: missing architectural components, scalability issues, security vulnerabilities, cost optimization opportunities, and technical-debt risks. For each, say whether it is a blocker or a nice-to-have, and propose a concrete change.

Tip

Copy-paste prompt for sequencing the todo list:

Take this todo list and identify the critical path, suggest which tasks can run in parallel, estimate total completion time, highlight blockers and their dependencies, and recommend the order I should implement them in.

Tip

Keep your artifacts where the AI can find them. Store PRDs in docs/requirements/, plans in docs/architecture/, and todos in docs/tasks/. Referencing them later with @docs/requirements/auth-prd.md lets any of the three tools reload the decisions you already made and stay consistent across features.

What’s Next

The Core Methodology: PRD to Plan to Todo The lighter quick-start version of this workflow.

Standard Workflow Patterns How this methodology fits the broader Plan, Execute, Verify loop.

Test-Driven Development with AI Drive each todo with a failing test before the AI implements it.

Domain-Driven Design Keep plans aligned with your domain model and bounded contexts.