| 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
- 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.
- 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.
- 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.
- Execute in plan order. Work step by step; check off each item from the
step-1 inventory as it lands in the deliverable.
- 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).
