Practice
Take a real task you'd otherwise hand over in one line — "add a search box," "clean up this messy file," "set up tests for this module." Before opening your assistant, write three short bullets, starting with Research: what would I want the assistant to find out first?
When the doing outruns the deciding checklist
- The Plan-First Protocol is three phases with different jobs: research (read and report), plan (propose and get approval), implement (build only the approved plan).
- One long prompt collapses research, decisions, and execution into a single hidden motion. Separating them creates checkpoints you control at the points where wrong turns would.
- Phases are joined by handoffs: a research report, then an approved plan. Each phase's "must not" guards against one of another chapter's failure modes.
- The rule for moving forward: advance only when the current phase's output could be handed to a stranger who'd know what to do.
- Your real work lives at those two review gates — judging whether there's enough context to plan, and whether the plan is worth building.
Why three phases beat one long prompt
It's tempting to think one very detailed prompt could get the same result — explain the task, the constraints, and the standards all at once, and let the assistant handle everything. That instinct is reasonable, and it fails for a specific reason.
The same task, two ways
Suppose the task is "let users export their reports as PDF." Run as one prompt, the assistant picks a PDF library, decides where the export button goes, invents a file-naming scheme, and wires it all up.
The protocol in one sentence
The Plan-First Protocol breaks one large request into three separate phases, each with a different job and a clear stopping point. Research: the assistant reads and reports — no code, no changes, just an account of what exists and what the task involves. Plan: the assistant proposes.