plan-before-executing

name

plan-before-executing

description

For any multi-step work, commit to an explicit ordered plan — steps, dependencies, and what done looks like — before producing the deliverable, then follow it and note deviations. Use this whenever a task has multiple parts, ordering constraints, dependencies, or deadlines, even if the user never says "plan" — rewrites with several required changes, research with sequenced questions, event or rollout schedules, runbooks, migrations, restructurings, multi-document deliverables, anything where step B needs step A's result. If you catch yourself about to start on the first piece of a many-piece task, that is the trigger.

Plan Before Executing

Diving straight into a multi-step task is where steps get skipped, dependencies get violated, and requirements silently fall out. Decomposing a problem into an ordered plan before solving it measurably reduces missed steps and wrong sequencing (Plan-and-Solve, Least-to-Most prompting), and disciplined operations put the plan half strictly before do/check/act for the same reason (Toyota A3 / PDCA): a plan is cheap to fix; a half-built deliverable is not.

Process

1. Extract everything the task requires. List every part, constraint, deadline, and dependency stated or implied in the input. This inventory is what protects you from dropping items later.
2. Order the steps by dependency, not by ease. For each step, note what it needs from earlier steps and any date or resource constraint. If two orderings both work, pick one and say so; if a stated constraint makes the task impossible, surface that now rather than mid-execution.
3. Define done before starting. Write what the finished deliverable contains and what would count as a violated constraint — this is the checklist you verify against at the end.
4. Execute in plan order. Work step by step; check off each item from the step-1 inventory as it lands in the deliverable.
5. Note deviations, don't hide them. If execution reveals the plan was wrong, adjust — and record what changed and why, so the final result and the stated plan agree.

What this looks like

• Event planning: venue is booked before invitations go out; catering headcount waits on the RSVP deadline; every task from the brief appears on the timeline.
• Research report: background questions are answered before the comparison section that depends on them; each source requested in the brief is used or its absence explained.
• Code migration: schema change ships before the code that reads the new column; the rollback step exists before the rollout begins.

Output rules

• Never narrate your own diligence. No "I carefully planned...", "having mapped all dependencies...", "as instructed, I first...". The discipline shows in a deliverable whose ordering is correct and complete — not in self-description.
• Keep output proportionate to the task. A five-step task needs a five-line plan, not a project charter.
• The planning happens before or while producing the answer; only its results appear in the output. Show the plan itself when the plan is the deliverable (runbook, schedule, rollout) or when the user needs to approve sequencing — otherwise just deliver work that follows it.

Grounding: Wang et al. 2023, Plan-and-Solve Prompting (arXiv:2305.04091); Zhou et al. 2022, Least-to-Most Prompting (arXiv:2205.10625); Toyota A3 / PDCA — plan precedes do/check/act (ASQ).