Flight Planning: file the plan before you take off

Here's the failure mode nobody warns you about. You hand an agent a PRD — the product requirements doc that says what to build — and you let it fly. Three hours later you have a confidently-built feature pointed at the wrong city.

At human speed, a wrong heading costs an afternoon. At agent speed it costs a whole session, and you don't find out until you read the diff.

Flight Planning is the fix. Before you build, you stop and file a plan — what you're building, how, and when you'll land — and you put it in front of other people. A pilot doesn't take off without filing one. Neither should you.

A vague plan, at agent speed, is the expensive kind

The cheapest place to catch a wrong heading is on the ground. Not at 30,000 feet, mid-session, with the fuel already burning.

That used to be a nice-to-have. When a person wrote the code, a half-formed plan self-corrected as they typed — they noticed the gap on line 40 and fixed it. An agent doesn't hesitate. Hand it an autonomous session — a build it runs end-to-end without you in the loop — and it executes the ambiguity at full speed, making every unstated decision at once, confidently, in one large diff.

So the economics flipped. The plan is no longer paperwork you produce after you know what you're doing. It's the thing that decides whether the session is worth running at all.

From crew on a boat to pilot of your own PRD

The shift underneath this is bigger than a meeting. It's a change in what you are.

The old model was a crew on a single boat. One sprint, one shared backlog, you pull a rope on a vessel someone else is steering, and your work only makes sense as part of the whole crew's effort. The new model gives you your own aircraft. One PRD, one owner, your flight path to fly. That's why a PRD should be scoped to one person and roughly a week of work — a pilot flies their own plane, they don't share a tiller.

And the moment everyone has their own aircraft, you need air traffic control. A crew on one boat coordinates by being in the same hull. A fleet of solo pilots coordinates by filing flight plans — this is where I'm going, this is what I'll build, these are the milestones, and this is when I'll land. Then everyone knows who's flying what and when they're due down. If a plane doesn't land on time, someone goes looking, instead of discovering the wreck a fortnight later.

Two things matter when you file. Be realistic — don't try to be a hero. About a week of work is a healthy range, the same fixed-appetite instinct that makes Shape Up work. And if the PRD is bigger than that, the plan isn't the first job — splitting the PRD is.

What a filed plan contains

A flight plan has four parts. The first three are the work. The fourth is optional, and underrated.

• The line — the explicit scope boundary. This is what I'm going to build, and this is what I'm not. Drawing the line is the act that turns a wish into a route.
• The briefs — the Prompt Briefs, one per atomic unit of work, each carrying testable acceptance criteria. A single PRD often files as 6 or 7 of them.
• The journey — milestones, a believed landing point, and an ETA. Not a hard deadline. A filed expectation, so deviation is visible.
• The red line (optional) — something tangible to react to. A couple of screens mocked up, even thrown together in an hour, just to bounce off. It's the red line drawn on a map between two cities. You'll bin it, but it translates the idea faster than a paragraph ever will.

Filed, it's a one-screen summary anyone can read in a minute:

Flight plan — project landing page
  The line     in: routing, tabs, feed cards · out: mobile, video reports
  The briefs   PB-1 redirect · PB-2 sticky tabs · PB-3 feed cards  (each: goal, scope, AC)
  The journey  3 briefs · lands ~Thursday
  Red line     2 mocked screens (optional)

One caution: the flight plan doc is a throwaway. Your PRD and its briefs stay the single source of truth. After the review, fold the decisions back into them and bin the plan. A second place that claims to be the truth is just confusion waiting to happen.

Who's in the room

This is the part the agent era quietly erodes, so I'll say it plainly: file the plan in front of people.

Working alone with a capable agent is fast and frictionless, and it's easy to never put your plan in front of another human. That's a trap. The agent is a calculator — rational, quick, and not remotely contextual. It will not think like your UX lead or your head of sales. That's the human's job, and the flight plan review is where it happens.

Stuart Leo

The agent sorts out the code. The humans bring the questions. That's the division of labour worth protecting.

Keep the room small but cross-disciplinary. The pilot, someone from software, a UX voice — and, when the work touches them, sales, finance, or whoever owns the end result. A scope problem caught by UX, or a commercial problem caught by sales, is trivial to fix in the plan and expensive to fix after the build. The review isn't a judgment. It's a bounce — several disciplines stressing the route while it's still cheap to change it.

Here's the honest cost: this asks you to stop and gather people before you've written a line, which feels slower in the moment. It is slower in the moment. It is much faster across the whole build, because the rework you didn't do never shows up on the bill.

The skill, and where it stops

I built a skill to prepare the plan — flight-plan. A skill is a packaged capability the agent runs on demand, a documented job with a fixed protocol. You invoke it in plain words: run flight-plan on this PRD. It reads the PRD, proposes the scope line, interrogates the spec for what's over- and under-specified, drafts the briefs, and plots the journey.

Then it stops. The skill files the plan and goes no further — it never builds, never takes off. Takeoff is a separate, human-gated step, which is the entire point of filing first.

A second agent works the other end. Where flight-plan builds the plan, a review-only verification agent stress-tests it — checking the acceptance criteria are actually testable and surfacing what the review still needs to decide. One proposes, the other challenges. It's the same pilot-directing-the-agents discipline C² runs everywhere, pointed at the plan instead of the code.

File the plan before you fly

Deviation in the air is fine — plans change, and you're the pilot. What's not fine is a wrong heading nobody can see.

So you file a flight plan before takeoff: the line, the briefs, the journey, reviewed out loud by the people who'll feel the result. Do that, and the wrong heading gets caught on the ground — not at 30,000 feet, with the session already burning.

Start here: read the method, run your first session, or browse the docs.