A Plan Is Not a To-Do List. It's a Thinking Trace.

I used to write implementation plans the way most developers do.

A bulleted list of tasks. Rough sequencing. The kind of thing that makes sense when you already know the codebase and have been thinking about the problem for three days.

They're useless to anyone else. They're often useless to you two weeks later.

The Framing That Changed How I Write Plans

The writing-plans skill from obra/superpowers contains a sentence that reframed the whole activity for me.

Write comprehensive implementation plans assuming the engineer has zero context for our codebase and questionable taste.

The second clause is the interesting one. Not "assume they're less experienced." Not "assume they need help." Assume they have questionable taste — meaning they'll make locally reasonable decisions that are globally wrong for this specific project, if you don't tell them not to.

This is a description of every developer stepping into an unfamiliar codebase. It's also, honestly, a description of an AI agent executing a task.

When I started writing plans to that standard, something unexpected happened: I started finding the gaps in my own understanding.

Plans as Compression Tests

Here's what I noticed. If I can't write down the exact file path, the exact function signature, and the exact test that verifies a step worked — I don't actually know what I'm building yet.

I thought I did. I had a clear mental model. But the mental model was tolerating ambiguity I hadn't noticed, because I was planning to resolve it "when I got there."

Writing a plan to the skill's standard forces that ambiguity into the open. Every step needs an exact command. Every code step needs actual code, not a description of code. Every verification step needs expected output.

The moment I write "add appropriate error handling" in a step, the skill's self-review catches it as a plan failure. Not a style note. A failure. Because "add appropriate error handling" is a thought that sounds like a task but contains no information about what to do.

The File Structure Section

There's a phase in the planning process that I now treat as the most important part.

Before any tasks, you map the file structure: what gets created, what gets modified, what each file is responsible for. This is where decomposition decisions get locked in.

Most developers make these decisions implicitly, on the fly, as they're writing code. The file structure phase asks you to make them explicitly, before any code exists.

This matters for a reason that's easy to miss. Decomposition decisions are hard to undo. If you build three features into one file because that seemed fine at 2am on day one, you're living with that boundary for the duration of the project. The plan is the one moment where restructuring is free.

Granularity as a Forcing Function

The task structure the skill demands is granular to the point where it feels almost excessive the first time you see it.

Each task has individual steps for: write the failing test, run it to confirm it fails, write the minimal implementation, run it to confirm it passes, commit. Two to five minutes per step.

The first time I followed this discipline, the build took longer than usual. The second time, I realized I'd been skipping verifications in my normal workflow — not because I was sloppy, but because I assumed success without checking. The third time, I caught a regression at the exact step where it was introduced, instead of an hour later when everything was tangled.

The granularity is a forcing function for the feedback loop. Smaller steps means shorter cycles between action and evidence.

What You're Actually Building

There's a framing buried in the skill's description of what a plan is for.

It says the plan exists so that an executing agent — human or AI — can work independently, with review checkpoints but without constant supervision. The plan is the context transfer mechanism. Everything the implementer needs to make good decisions is in the document.

That's a different conception of what a plan is than a reminder list for yourself.

When I write to that standard, the plan survives context switches. It survives handing work off. It survives coming back to a project after three weeks away. And it surfaces, at writing time, everything I was planning to remember but hadn't written down — which is always more than I thought.

I now think of writing a plan as the moment I find out whether I actually understood the work, or whether I just thought I did.

---

Part of the Superpowers series — 14 specialist skills from obra/superpowers.