PRD → Plan → Todo Workflow

Transform product requirements into production-ready code using Claude Code’s powerful planning and execution workflow. This guide teaches you the battle-tested methodology used by Anthropic’s engineering teams to build features systematically and reliably.

The Core Methodology

Why PRD → Plan → Todo Works

This workflow transforms chaotic development into a predictable process:

PRD (Product Requirements Document) - Define what to build
Plan - Let Claude think through how to build it
Todo - Execute the plan step by step
Iterate - Refine based on feedback

The result? Complex features built right the first time, with clear traceability from requirements to code.

Starting with Requirements

Creating Effective PRDs

The quality of your output depends on the clarity of your input. Here’s how to structure requirements for Claude:

# Feature: User Wishlist System

## Overview
Users need to save products for later purchase and share collections with friends.

## User Stories
- As a user, I want to create multiple wishlists
- As a user, I want to add/remove products from wishlists
- As a user, I want to share wishlists via public link
- As a visitor, I want to view shared wishlists (read-only)

## Technical Requirements
- Max 50 items per wishlist
- Max 10 wishlists per user
- Public links expire after 90 days
- Track view counts for analytics

## Acceptance Criteria
- [ ] Users can CRUD wishlists
- [ ] Products can be added/removed
- [ ] Share links work without auth
- [ ] View tracking implemented

# PRD: Advanced Search Feature

## Problem Statement
Users struggle to find specific content in our 100k+ document library.
Current search returns irrelevant results and lacks filtering options.

## Goals
- Improve search relevance by 50%
- Reduce time-to-find from 5min to 30sec
- Enable power users to create complex queries

## Functional Requirements

### Search Capabilities
1. Full-text search with stemming
2. Fuzzy matching for typos
3. Boolean operators (AND, OR, NOT)
4. Phrase search with quotes
5. Wildcard support (*, ?)

### Filtering Options
- Date range (created, modified)
- Document type (PDF, DOC, MD)
- Author/owner
- Tags and categories
- File size ranges

### UI Requirements
- Search-as-you-type with debouncing
- Result preview snippets
- Faceted filter sidebar
- Search history (last 10)
- Saved searches for users

## Non-Functional Requirements
- Response time < 200ms for 95th percentile
- Support 1000 concurrent searches
- Mobile-responsive design
- Accessibility (WCAG 2.1 AA)
- Works offline for cached results

## Technical Constraints
- Use existing Elasticsearch cluster
- Integrate with current auth system
- Maintain backward compatibility
- Budget: 2 engineer-weeks

## Success Metrics
- Search success rate > 80%
- Average results clicked in top 3
- User satisfaction score > 4.5/5

# API Enhancement: Bulk Operations

## Endpoints Required

### POST /api/v2/products/bulk
- Accept array of product objects (max 100)
- Validate all before processing any
- Return detailed error array
- Support partial success mode

### PUT /api/v2/products/bulk
- Update multiple products by ID
- Support field-level updates
- Maintain audit trail
- Rate limit: 10 requests/minute

### DELETE /api/v2/products/bulk
- Soft delete by default
- Require extra confirmation header
- Return deleted count
- Log all deletions

## Request/Response Formats

// Request
{
  "products": [...],
  "options": {
    "validate_only": false,
    "partial_success": true
  }
}

// Response
{
  "success": 85,
  "failed": 15,
  "errors": [
    {
      "index": 2,
      "code": "INVALID_SKU",
      "message": "SKU already exists"
    }
  ]
}

## Error Handling
- Validation errors: 400
- Auth errors: 401/403
- Rate limit: 429
- Server errors: 500

Feeding PRDs to Claude

Once you have a PRD, here’s how to effectively communicate it to Claude:

Start with context

> We need to implement a new feature. Here's the PRD:
[paste PRD content]
Based on our tech stack (Next.js 15, Postgres, Clerk auth),
please analyze this and identify any questions or concerns.

Let Claude ask clarifying questions

Claude: I have a few questions about the wishlist feature:
1. Should wishlist names be unique per user?
2. Can products be in multiple wishlists?
3. What happens if a product is deleted?
4. Should we track who added each item?

Refine requirements together

> Good questions! Let me clarify:
1. No, users can have duplicate names
2. Yes, products can be in multiple lists
3. Keep as "unavailable" with metadata
4. Yes, track added_by and added_at

Confirm understanding

> Please summarize your understanding of the requirements
and any technical decisions we've made.

Save refined PRDs to CLAUDE.md for future reference:

# Feature context: Wishlist System (Nov 2024)
# Decisions: Keep deleted products, allow duplicates
# Tech: Postgres JSONB for metadata, Redis for view counts

Planning with Deep Reasoning

Activating Claude’s Thinking Modes

Claude Code offers multiple thinking levels for different complexity needs:

Thinking Mode Spectrum

Trigger	Tokens	Use Case
(default)	~500	Simple tasks, clear path
`think`	~5,000	Standard feature planning
`think hard`	~10,000	Complex architectures
`think harder`	~20,000	Multi-system integration
`ultrathink`	~128,000	Major refactoring, migrations

Choose based on complexity, not importance. A critical bug fix might need default mode, while a new microservice needs ultrathink.

Planning Workflow

For typical features (think mode):

> Based on the wishlist PRD, think about the implementation approach.
Consider database schema, API design, and UI components.

Claude’s response might include:

I'll think through this systematically...

## Database Schema
- wishlists table: id, user_id, name, created_at, is_public
- wishlist_items: id, wishlist_id, product_id, added_by, added_at
- wishlist_views: for analytics tracking

## API Structure
- REST endpoints under /api/wishlists
- GraphQL might be better for nested data
- Need rate limiting for public endpoints

## Implementation Phases
1. Database migrations and models
2. CRUD API with tests
3. Frontend components
4. Sharing mechanism
5. Analytics integration

## Considerations
- Index on user_id for performance
- Redis for view counts (avoid DB writes)
- UUID for share links (not sequential IDs)
- Soft delete for data recovery

For architectural decisions (ultrathink mode):

> We're migrating from REST to GraphQL across 50+ endpoints serving
> 1M+ daily users. Ultrathink about the migration strategy,
> including zero-downtime deployment, gradual rollout, and rollback plans.

This triggers extended reasoning where Claude will:

Analyze existing API patterns
Design parallel-run architecture
Create detailed migration phases
Plan monitoring and rollback triggers
Consider edge cases and failure modes
Propose testing strategies

Build plans through conversation:

> Let's plan the authentication refactor. Start by analyzing
> our current JWT implementation.

[Claude analyzes]

> Good analysis. Now think about migrating to Clerk while
> maintaining backward compatibility.

[Claude extends plan]

> What about session migration for logged-in users?

[Claude refines further]

This approach helps you guide Claude’s thinking in the right direction.

Evaluating Plans

Before proceeding to implementation, validate Claude’s plan:

Check completeness
- Does it address all PRD requirements?
- Are edge cases considered?
- Is error handling specified?
Assess feasibility
- Are time estimates realistic?
- Do we have required dependencies?
- Any blocking technical constraints?
Review architecture fit
- Aligns with existing patterns?
- Maintains system boundaries?
- Follows team conventions?

Consider alternatives

> What alternative approaches did you consider?
> Why did you choose this one?

Converting Plans to Todo Lists

The Todo List Approach

Claude Code excels at breaking plans into executable tasks. This systematic approach ensures nothing falls through the cracks:

## Wishlist Feature Implementation Tasks

### Phase 1: Database Setup ✅
- [x] Create migration for wishlists table
- [x] Create migration for wishlist_items table
- [x] Add indexes for performance
- [x] Create Prisma models
- [x] Seed test data

### Phase 2: Backend API (In Progress)
- [x] POST /api/wishlists - Create wishlist
- [x] GET /api/wishlists - List user wishlists
- [ ] GET /api/wishlists/:id - Get single wishlist
- [ ] PUT /api/wishlists/:id - Update wishlist
- [ ] DELETE /api/wishlists/:id - Delete wishlist
- [ ] POST /api/wishlists/:id/items - Add item
- [ ] DELETE /api/wishlists/:id/items/:itemId - Remove item
- [ ] GET /api/wishlists/shared/:shareId - Public view

### Phase 3: Frontend Components
- [ ] WishlistCard component
- [ ] WishlistGrid layout
- [ ] AddToWishlist button
- [ ] ShareWishlist modal
- [ ] WishlistManager page

### Phase 4: Testing & Polish
- [ ] API integration tests
- [ ] Component unit tests
- [ ] E2E test scenarios
- [ ] Performance optimization
- [ ] Documentation update

Working with Todo Lists

Most efficient for standard features:

> Implement the wishlist feature based on our plan.
> Work through the tasks systematically, testing each phase
> before moving to the next.

[Claude starts with Phase 1, creates migrations, runs them,
confirms success, then moves to Phase 2...]

Claude will:

Execute tasks in order
Run tests after each step
Ask for confirmation at phase boundaries
Update the todo list as it progresses

Better for complex or sensitive changes:

> Let's implement Phase 1 of the wishlist feature.
> Show me the migrations before running them.

[Claude shows migration files]

> Good, run the migrations and create the models.

[Claude executes]

> Now let's start on the API. Begin with the create endpoint.

[Claude implements POST /api/wishlists]

> Add validation for the name field - max 50 chars.

[Claude updates with validation]

Use Claude’s task tool for independent items:

> These API endpoints are independent. Use subagents to
> implement them in parallel:
> - GET /api/wishlists
> - POST /api/wishlists
> - DELETE /api/wishlists/:id

Claude will spawn multiple agents to work simultaneously.

Tracking Progress

Claude can maintain a progress log as it works:

# Wishlist Implementation Progress

## Completed Today
- ✅ Database schema created and migrated
- ✅ Prisma models generated
- ✅ Basic CRUD API (6/8 endpoints)
- ✅ Input validation middleware
- ✅ Rate limiting added

## Currently Working On
- 🔄 Share link generation logic
- 🔄 Public view authorization

## Blockers
- ❌ Redis not configured for view counts
  - Solution: Use DB for now, migrate later

## Next Steps
- Complete remaining API endpoints
- Start frontend components
- Add comprehensive tests

## Notes
- Decided to use UUIDs for share links
- Added soft delete for recovery
- Rate limit: 100 requests/minute for public endpoints

Iterating on Implementation

Handling Feedback

As you review Claude’s work, provide feedback effectively:

Be specific about issues

❌ "The API doesn't work right"
✅ "The API returns 500 when wishlist name is empty.
    Add validation to return 400 with clear error message."

Provide examples

> The share link should look like: myapp.com/wishlist/share/abc123
> Not: myapp.com/api/wishlists/123/public

Reference best practices

> Follow our API error format from CLAUDE.md:
> { error: { code: "VALIDATION_ERROR", message: "..." } }

Iterate quickly

> Fix the validation issue, then continue with the next endpoint.
> Don't refactor everything yet.

Common Iteration Patterns

> The wishlist creation is failing. Write a failing test
> that reproduces the issue first.

[Claude writes test]

> Now fix the implementation to make the test pass.

[Claude fixes code]

> Add edge case tests for empty names and special characters.

> The basic feature works. Now add:
> 1. Optimistic UI updates
> 2. Loading states
> 3. Error boundaries
> 4. Retry logic

> Implement one at a time so we can test each.

> The wishlist page loads slowly with 50 items.
> Profile it and identify bottlenecks.

[Claude analyzes]

> Implement the top 3 optimizations and measure impact.

[Claude optimizes and reports metrics]

Real-World Example

Complete Feature Flow

Here’s how a senior developer uses the PRD → Plan → Todo workflow:

> I need to implement a notification system. Here's the PRD:
> [pastes 200-line PRD about email/push/in-app notifications]

Claude: I'll analyze this PRD. I notice it mentions three notification
channels but doesn't specify priority. Should all three be implemented
together or can we phase them?

> Let's phase it: email first, then in-app, push last.

> Based on this, think hard about the implementation approach.
> Consider scalability for 100k daily notifications.

Claude: [Extended thinking about architecture, queue systems,
delivery tracking, template management, user preferences...]

Here's my implementation plan:
1. Message queue with Redis/BullMQ for reliability
2. Template system using Handlebars
3. Provider abstraction for easy switching
4. Delivery status tracking in Postgres
5. User preferences with channel-level opt-out

> Excellent plan. Create a detailed todo list for phase 1 (email only).

Claude: [Generates 25-task todo list organized by component]

> Let's start. Work through the infrastructure tasks first.

[Claude implements Redis setup, queue configuration, worker process...]

> The queue is processing too slowly. We need 10k/hour throughput.

Claude: I'll add concurrent workers. Currently single-threaded...
[Updates to use 5 concurrent workers, adds batching]

> Much better. Continue with the email templates.

[Session continues for 2 hours, feature ships same day]

Best Practices

PRD → Plan → Todo Success Factors

DO:

Start with clear, detailed requirements
Let Claude think before implementing
Break work into verifiable chunks
Test each phase before proceeding
Keep progress logs for complex features
Iterate based on concrete feedback

DON’T:

Jump straight to coding
Give vague requirements
Try to build everything at once
Skip the planning phase
Ignore Claude’s clarifying questions
Refactor while implementing

Tips from Power Users

“Think of Claude as a junior architect” - It can create solid plans but needs your expertise to validate architectural decisions.
“Requirements are prompts” - The clearer your PRD, the better Claude’s output. Invest time upfront.
“Plans are living documents” - Update them as you learn. Claude can revise plans based on implementation discoveries.
“Todo lists prevent drift” - They keep Claude focused and prevent it from over-engineering or going off track.
“Phase boundaries matter” - Complete and test each phase. This provides natural checkpoints for review.

Next Steps

Now that you understand the PRD → Plan → Todo workflow:

Deep Reasoning Master thinking modes for complex problems

MCP Setup Integrate external tools into your workflow

Testing Workflow Build quality in from the start

Remember: Great software isn’t built by accident. The PRD → Plan → Todo workflow ensures every feature is thoughtfully designed, carefully implemented, and thoroughly tested. Master this methodology and watch your productivity soar!