Approve the plan before the code exists

Code review happens after the decisions that actually shaped the change have already been made. By the time a pull request lands in front of a reviewer, the sequencing, the affected files, and the tradeoffs between approaches are already baked into a diff. Disagreeing at that point means asking for a rewrite, not a redirection.

Planner exists to move that conversation earlier. It generates a repository-aware implementation plan before any code is written, and now that plan goes through the same kind of review a pull request would get, before implementation starts rather than after.

Why review needs a checkpoint before the diff

Engineering managers and staff engineers already do this work informally. They read a ticket, sketch the approach in a comment or a doc, and get a teammate to sanity check it before anyone opens an editor. Planner formalizes that step instead of leaving it to whoever remembers to do it. A plan captures the affected repositories and files, the order operations should happen in, how changes across multiple repositories need to line up, open questions that still need an answer, and how the change should be verified once it exists.

That is enough structure to review meaningfully, and specific enough that a reviewer can catch a bad sequencing decision or a missed cross-repo dependency before it turns into rework.

What the approval workflow adds

A plan is a living document while it is under review, not a single frozen artifact. Feedback changes it, and the tooling now tracks that instead of losing it.

Versions and a version picker. Every revision to a plan is saved as its own version. A version picker lets reviewers move between them to see exactly what changed in response to feedback, instead of only ever seeing the latest state and having to guess what was different before.

Comments pinned to plan sections. Reviewers can attach a comment to a specific section: a particular file, a step in the change sequence, or an open question, rather than leaving one general note on the whole plan. That keeps feedback attached to the part of the plan it is actually about, even as later versions revise the rest.

Mermaid diagrams, rendered inline. Plans that describe a flow, a sequencing decision, or an architecture change can include Mermaid diagrams. They render inline in the plan view, so a reviewer follows the diagram next to the prose instead of reading raw diagram syntax and mentally compiling it.

An explicit approval gate. A plan needs to be approved before implementation can start. Reviewers either approve it, letting implementation proceed, or request changes, sending it back with comments attached to the sections that need to change.

What this changes day to day

For a team adopting AI coding agents, this closes a real gap. Agents are fast enough to generate a plausible-looking implementation before anyone has agreed on the approach, and unwinding that after the fact costs more than reviewing the plan would have. Making the plan itself a reviewable, approvable artifact means the conversation about approach happens once, on the plan, instead of repeatedly in PR comments on code that already exists.

If your team is already running Planner, the approval workflow is the natural next step: turn the plan from something one person reads before kicking off implementation into something the team actually reviews.