Psst. This one looks best in fullscreen. It also has light music, so turn the volume down if you're somewhere public.
Your download has started.
Confession: I haven’t paid Apple’s $99 a year developer fee yet, so macOS won’t trust OpenPlan on first launch. Drag it to Applications, then run this once in Terminal:
xattr -dr com.apple.quarantine /Applications/OpenPlan.appRather click? Open OpenPlan, click Done, then go to System Settings, Privacy & Security and click Open Anyway.
Agents are great at building features, fixing bugs, optimizing code, and a myriad of other things. But one thing I’ve repeatedly noticed is how easily they miss the context a team builds up over the years: why the product works the way it does, what customers keep asking for, and which past decisions still matter.
I’ve seen this pattern play out more than once, and it has bitten us back every single time. An agent makes a reasonable assumption, fills in a gap in the requirements, and builds something that technically works but isn’t quite what we needed.
You could argue that this can be solved with good documentation and retrieval mechanisms. And to some extent, it can. But even with all the right documents, agents often miss the bigger picture. Product context changes over time, and documentation inevitably gets out of date.
Generally, an agent works from an initial prompt, context about the repo, and any additional docs it can find. That’s rarely the whole picture.
An agent can be great at executing a task, but it can still:
Yeah, agents can write code and solve the problem in front of them. Whether it’s the right problem to solve is a separate question.
Why code review alone doesn’t catch it
Most workflows with coding agents follow roughly the same five steps:
- Gap opens
- Plan checked
You describe the task in a prompt.
The prompt carries only what you remembered to write down.
The agent asks a few clarifying questions.
A few questions can't carry your team's context, so the agent fills gaps with guesses.
The agent writes a plan from what it understood.
A misunderstanding from step 2 turns into a clean plan for the wrong problem.
You review the plan the agent wrote.
Review checks the plan as written. It can't see the question nobody asked.
The agent builds it, and code review follows.
Changing direction now costs the most, because the code already exists.
We do review the code after implementation, but there’s a problem. If the agent or human reviewing the code is working from an already misaligned plan, they might not even know it. It’s easy to approve something that’s technically correct without realizing it solves the wrong problem.
One solution is to introduce a review step at the planning stage. But reviewing long, complex plans can become tedious, especially when there’s a lot to go through.
The real gap is at step 2.
A few quick clarifying questions aren’t enough to transfer the context a team carries in its head. Files like CLAUDE.md help, but they’re better suited to general instructions and conventions than capturing the intent behind a specific piece of work.
Introducing OpenPlan
Alignment shouldn’t depend on how complete the initial prompt was or how many questions the agent happened to ask.
OpenPlan gives every piece of work a defined lifecycle, with explicit states and rules for moving between them.
The plan is the basic unit of work. A single plan can span multiple repositories and multiple agent sessions.
To be honest, OpenPlan is mostly a nice way to manage Markdown files and other metadata. But, that’s the point. The value isn’t in the files themselves, but in the structure around them. It makes alignment a fixed part of every plan rather than something that happens only when someone remembers to do it.
The plan lifecycle
Every plan moves through six states. Alignment is the gate: no code gets written until it’s complete.
The agent files the first version of the plan. You comment on it until it reads right.
Sending your first review opens alignment.
Four personas take turns asking questions. Each answer raises the alignment score.
Build unlocks once every question has an answer and the score reaches your target.
Agents work through the todo list. A new requirement you raise becomes a new todo.
It moves to review once no todo is open. You can reopen alignment.
The work waits on review: an agent review, a human review on GitHub, or CI checks.
You mark the plan completed once every PR is merged.
Every PR for the plan is merged, and you've confirmed it.
Only you can complete a plan. Agents stop at in review.
Any plan can be archived. It sits behind a collapsed toggle on the board and table views.
Only you can archive a plan, from any state.
Read the six states as a list
- Draft. The agent writes the first version of the plan. I review it and give feedback until it reads right.
- Alignment. The agent asks me questions until we agree on what to build, why it matters, and how we’ll approach it. The outcome is a todo list for the plan. More on this below.
- In progress. Agents work through the todo list. If I introduce a new requirement along the way, it’s automatically added to the todo list.
- In review. Once the implementation is completed and waiting for review. This could be an agent review, a human review on GitHub or a similar platform, or CI checks.
- Completed. All PRs associated with the plan have been merged.
- Archived. Any plan can be archived. Archived plans sit behind a collapsed toggle in the board or table view.
Alignment: the step that matters most
This is where OpenPlan gets opinionated. Before any code is written, the agent and I need to agree on what we’re building, why it’s worth building, and how we’ll build it (it’s okay even if I’m not sure how.)
How it works
The agent drafts questions, each with a few options (always with free text option). Intentionally, the agent never makes any decision. The goal is to help develop product and engineering taste, not to take decisions off my plate.
As we work through the questions and agree on the requirements and approach, the alignment score increases. This score determines whether an agent can start implementing the plan.
Who needs this export first?
What should Export do when the filters match no orders?
What happens if an export fails halfway?
What happens when an export has 500,000 rows?
Why an app and not just a skill?
A skill would get me most of the way there. Something like Matt Pocock’s /grill-me already makes an agent question you before it starts building, and it works well.
I built an app anyway, for three reasons.
I enjoy using well-designed interfaces, and I tend to come back to tools I enjoy. If the alignment process feels good to go through, I’m more likely to do it every time.
Some people might see this as bloat. For me, it helps make the habit stick.
OpenPlan is a low-stakes place to experiment with different flows and interactions. At work, I build for enterprise B2B customers, where the stakes are too high to experiment as freely.
Right now, agents can build and iterate quickly, but they’re not particularly good at knowing what feels great to use. They can learn from existing interfaces and past design research, but tools for working with agents are still relatively new.
I think their design should come from how people actually work with agents today, rather than from patterns built for a different time.
For the design, I learned a lot from 
Linear, which has one of the friendliest interfaces I’ve used. I also drew inspiration from 
Arc browser (they have some of the cleanest UX, especially onboarding), 
xAI’s approach to bots, 
Notion, 
OpenAI, and 
Anthropic.
I respect the care these teams put into their products, and I wanted to bring some of that thinking into OpenPlan.
Making plans easier to understand
Long plans are slow to read, and it’s easy to miss a misunderstanding buried somewhere in the middle.
To address this, OpenPlan can generate short explainer videos of a plan using Remotion. A video can communicate the main flows much faster than pages of text.
It costs more tokens, but I think that’s worth it.
Trade-offs I’m willing to make
OpenPlan comes with a few trade-offs that I’m happy to accept:
What’s next
OpenPlan is still changing. I’ll share more as I make progress. Cheers!
Comments