The Core Methodology: PRD to Plan to Todo

The single most effective and reliable workflow for building features with an AI assistant is the PRD → Plan → Todo methodology. This structured approach transforms a high-level requirement into a detailed engineering plan, ensuring that both you and your AI partner are perfectly aligned before writing a single line of code.

This guide breaks down each step of this core workflow, providing a repeatable process for tackling any development task.

The Three Phases of the Core Methodology

The workflow moves from high-level business needs to granular, executable tasks.

1. PRD: The Source of Truth

Everything starts with a clear requirement. This can be a formal Product Requirements Document (PRD), a user story, a ticket, or even a detailed bug report. This document serves as the “source of truth” that defines the what and the why of the task.

2. Plan: The Architectural Blueprint

In this phase, you collaborate with the AI to translate the PRD into a technical implementation plan. You act as the senior architect, guiding the AI as it explores the codebase, suggests architectural approaches, and outlines the major components to be built or modified.

3. Todo: The Actionable Checklist

Finally, you and the AI convert the high-level plan into a granular, step-by-step todo list. Each item on this list is a small, concrete task that can be implemented and verified independently. This checklist becomes the script that the AI will follow during the execution phase.

---

Step-by-Step Implementation

Here’s how to apply the PRD → Plan → Todo workflow in practice.

Phase 1: Ingesting the PRD

1. Make the PRD Accessible. Place your PRD or user story inside your project repository, typically in a /docs directory (e.g., docs/feature-x-prd.md). This makes it easy to reference.

2. Provide the PRD as Context. Start your conversation with the AI by giving it the PRD as the primary context.

   I'm starting work on a new feature. Please read the requirements in @/docs/feature-x-prd.md.

Phase 2: Collaborative Planning

The single most important rule of this phase: stop the AI from writing implementation code. Every modern tool now ships a first-class plan mode that is read-only by design, so you no longer have to beg the model to “not code yet.”

Cursor

Switch the Agent to Plan mode (the mode dropdown in the chat input, or Ask mode if you only want a discussion). Plan mode researches the codebase and proposes edits without applying them until you accept. Reference your PRD with @docs/feature-x-prd.md so the plan is grounded in the requirement.

Claude Code

Type /plan to enter plan mode. Claude explores the repo read-only and presents a plan you approve before any file is touched. There is no /think slash command; extended thinking is a separate toggle (Option+T on macOS, Alt+T on Windows/Linux, after running /terminal-setup) or you can raise the effort level in /model. Note that typing words like “think hard” or “ultrathink” in your prompt no longer allocates a thinking budget, they are treated as ordinary instructions.

Codex

Toggle /plan-mode in the Codex TUI for multi-step planning, or launch with a read-only sandbox: codex --sandbox read-only. Put durable project context in AGENTS.md at the repo root so every Codex session loads your conventions automatically.

Tip

Copy-paste prompt for the planning phase:

Based on the PRD in @docs/feature-x-prd.md and your analysis of the existing codebase, produce a high-level implementation plan. Do NOT write any implementation code yet. Cover the changes needed in the database, backend, and frontend, call out the files you would touch, and list every assumption or open question you need answered before you can plan confidently.

The AI will produce a plan, perhaps suggesting new database tables, API endpoints, and UI components. This is the most critical part of your role as the architect: review the plan and pressure-test it before any code exists.

Tip

Copy-paste prompt for refining the plan:

The plan looks solid overall. Before we proceed: what are the security implications of the new public-facing endpoint, and how will we handle authentication and rate limiting? Also confirm this approach does not conflict with the existing data model in @src/db/schema.ts. Revise the plan to address these.

Continue this back-and-forth until you have a technical plan you are confident in. You have front-loaded the architectural thinking, which is exactly what stops the AI from sprinting down the wrong path during implementation.

Phase 3: Generating the Todo List

Once the plan is solid, ask the AI to convert it into a granular checklist. The goal is tasks small enough to implement and verify one at a time.

Tip

Copy-paste prompt for generating the todo list:

Convert the approved plan into a detailed todo list in Markdown. Each item must be a single, concrete task completable in under two hours, ordered by dependency, and tagged with its area (Database / Backend / Frontend / Tests). Add a one-line acceptance criterion to each task so we know when it is done.

The AI will generate a granular checklist that looks something like this:

- [ ] **Database:** Add `is_active` boolean column to `widgets` table (migration + rollback).
- [ ] **Backend:** Create a new `GET /api/widgets/:id` endpoint returning the widget with its status.
- [ ] **Backend:** Modify `POST /api/widgets` to set `is_active` to `true` on creation.
- [ ] **Frontend:** Create a `WidgetStatus` React component that renders the active/inactive badge.
- [ ] **Frontend:** Mount `WidgetStatus` on `WidgetDetailsPage`.
- [ ] **Tests:** Add an integration test covering the new endpoint and the status toggle.

Each tool then tracks that list differently as you execute it:

Cursor

Keep the checklist in a Markdown file (for example docs/feature-x-todos.md) and reference it with @. In Agent mode, ask Cursor to work the list top to bottom and check off items as it completes them, reviewing each diff before you accept.

Claude Code

Claude Code maintains its own in-session todo list and updates it as it works through multi-step tasks. Paste your checklist and say “track these as your todos and implement them one at a time, pausing after each for review.”

Codex

Codex streams a live plan (turn/plan/updated) with each step marked pending, in-progress, or completed, so you can watch it tick through the list. Keep the canonical checklist in the repo and let Codex update the file as it goes.

With this detailed todo list, you are ready to move into the Execute and Verify phases. You have transformed a vague requirement into a precise, actionable engineering plan, setting your AI partner up for a smooth implementation.

When This Breaks

Even with a clean plan, three failure modes show up repeatedly. Each has a fast recovery.

Caution

The AI starts coding during the plan phase. Despite the read-only instruction, an over-eager model occasionally emits implementation code. Stop it immediately rather than letting the plan drift into half-built code.

Stop. We are still in the planning phase. Discard any code you started and return to a written plan only. List the files you intend to change and why, but do not write their contents yet.

Caution

The plan ignores an existing constraint. The model proposes an approach that conflicts with your current architecture (duplicates a service, breaks an API contract, ignores an auth layer). Point it at the specific file and force a reconciliation.

Your plan adds a new auth flow, but we already centralize auth in @src/middleware/auth.ts. Rework the plan to reuse the existing middleware instead of introducing a parallel path, and flag anything that genuinely cannot reuse it.

Caution

Todos are too coarse. Tasks like “build the backend” are unverifiable and invite the AI to over-reach. Split them before you implement.

The task “implement the widgets API” is too large. Break it into separate tasks per endpoint, each with its own acceptance criterion, and isolate the migration and tests as their own items.

What’s Next

The PRD to Plan to Todo Methodology (Deep Dive) Full templates, real-world examples, and per-tool execution details.

Standard Workflow Patterns How PRD to Plan to Todo fits the broader Plan, Execute, Verify loop.

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