Skip to content
Developer Toolkit Developer Toolkit Cursor, Claude Code & Codex | Developer Toolkit

The PRD to Plan to Todo Methodology

You have a Jira ticket that says “Add user notifications.” Your PM wants it by Friday. You open Cursor, Claude Code, or Codex, paste the ticket description, and hit enter. The AI generates 400 lines of code that looks plausible but misses half the requirements, invents a notification table schema that conflicts with your existing database, and ignores your team’s API conventions entirely.

The problem is not the AI. The problem is that you skipped the planning phase and asked a probabilistic system to make architectural decisions it is not qualified to make.

What You’ll Walk Away With

Section titled “What You’ll Walk Away With”
  • A repeatable three-phase workflow (PRD, Plan, Todo) that works across Cursor, Claude Code, and Codex
  • Copy-paste prompts for each phase that you can use on your next feature
  • A strategy for keeping the AI focused on implementation while you own the architecture
  • Techniques for saving your plan as a reusable artifact that survives context resets

The Three Phases

Section titled “The Three Phases”

The PRD to Plan to Todo methodology separates thinking from doing. You invest 15-20 minutes in structured planning to save hours of debugging and rework.

Phase 1: Ingest the PRD

Section titled “Phase 1: Ingest the PRD”

Every feature starts with a requirement. It might be a formal Product Requirements Document, a user story, a Slack message from your PM, or a bug report. Whatever form it takes, you need to get it into your AI tool as the foundational context.

The key principle: the AI reads the requirement, but you validate its understanding before it writes a single line of code.

Place your PRD in the repository (e.g., docs/notifications-prd.md). Open Agent mode and reference it directly:

Read @docs/notifications-prd.md and summarize the key requirements.
List any ambiguities or missing details I should clarify before we plan.
Do not write any code yet.

Cursor’s Agent will read the file, cross-reference it against your codebase using semantic search, and surface questions you might not have considered. Use @codebase to let it scan for existing patterns.

Phase 2: Collaborative Planning

Section titled “Phase 2: Collaborative Planning”

With the requirements understood, you now co-create the implementation plan. This is where your architectural expertise matters most. The AI proposes, you evaluate, and together you refine until the plan is solid.

Stay in Agent mode. Ask for a structured plan and iterate on it:

Based on the PRD and your analysis of the codebase, create a
high-level implementation plan covering:


1. Database schema changes (migrations)
2. Backend API endpoints (following our existing patterns in src/api/)
3. Frontend components (following our component patterns)
4. Integration points with existing notification systems


Do not write code. Output the plan as a markdown document.

Review the plan carefully. Push back on architectural decisions:

The plan proposes a new notifications table, but we already have
an events table that could be extended. What are the trade-offs
of each approach? Which aligns better with our existing patterns?

Phase 3: Generate the Todo List

Section titled “Phase 3: Generate the Todo List”

The plan becomes a checklist. Each item should be small enough to implement and verify in a single AI interaction. This is what makes the methodology reliable: instead of asking the AI to build an entire feature, you give it one focused task at a time.

Convert the implementation plan into a detailed, ordered todo list.
Each task should:
- Be implementable in a single focused session
- Have clear acceptance criteria
- Include the specific files to modify
- Be ordered so each task builds on the previous one


Save this as docs/notifications-todo.md

Cursor tracks todo items natively. You can reference the todo file throughout implementation with @docs/notifications-todo.md and ask Cursor to mark items complete as you go.

The Execution Loop

Section titled “The Execution Loop”

With your todo list in hand, implementation becomes a predictable loop:

  1. Pick the next unchecked task from the todo list
  2. Give the AI the task with the plan as reference context
  3. Let the AI implement it
  4. Verify (run tests, review the diff)
  5. Commit the change
  6. Repeat

Each iteration is small, reviewable, and reversible. If the AI goes off track on task 7, you only lose the work from that one task, not the entire feature.

When This Breaks

Section titled “When This Breaks”

The PRD is too vague. If the requirement is “make notifications better,” no amount of methodology will save you. Push back on your PM or write a more specific PRD yourself. The AI can help: ask it to generate a PRD template and fill in what you know.

The plan is too ambitious. If your plan has 40+ todo items, the feature is too big for one cycle. Split it into milestones that each deliver user-visible value. Ship milestone 1 before planning milestone 2.

The AI drifts from the plan. Context window limits mean the AI may “forget” earlier planning in long sessions. Reference the plan file explicitly in every prompt (@docs/notifications-plan.md). In Claude Code, use /clear between tasks and re-reference the plan. In Codex, use separate threads per task.

You skip the planning phase “just this once.” Every developer who has tried to skip straight to implementation has learned the same lesson: the time you save skipping the plan, you spend tripling on debugging. The 15-minute planning investment pays for itself on every feature larger than a one-file change.

What’s Next

Section titled “What’s Next”
Test-Driven Development Add TDD to your PRD-Plan-Todo workflow for built-in verification at every step.
Human in the Loop Learn when to intervene during execution and when to let the AI run.
Context Windows Understand how token limits affect long planning and implementation sessions.