Planner
Generate a repository-aware implementation plan before code is written, then review and approve it.
Planner generates an implementation plan before any code is written. Instead of letting a coding agent jump straight into edits, Planner analyzes the request against the current state of your repositories and produces a plan that a human can read, question, and approve.
Starting a planning session
Start a planning session from a coding agent with:
/baz:plan-with-bazThis kicks off a planning run scoped to the task at hand. The agent gathers context from the relevant repositories before producing a plan, rather than proposing changes from the prompt alone.
What a plan captures
| Section | Description |
|---|---|
| Affected repos and files | Every repository and file the change is expected to touch |
| Change sequence | The order operations should happen in, including dependent steps |
| Cross-repo coordination | How changes across multiple repositories need to line up with each other |
| Open questions | Ambiguities or decisions that need an answer before implementation |
| Verification steps | How the change should be tested or validated once it is implemented |
By surfacing this before implementation starts, Planner turns architectural and sequencing decisions into something reviewers can weigh in on, rather than discovering them after the fact in a diff.
Plans workspace
Every plan lives in the Plans workspace. From there you can:
- See all plans across repositories, along with their current status
- Open a plan to inspect its sections, affected files, and open questions
- Track which plans are awaiting review, approved, or already in implementation
The workspace is the entry point for reviewers, not just the person who requested the plan.
Reviewing and approving a plan
Plan review works like code review, but it happens before the code exists.
Plan versions and the version picker
A plan can be revised after feedback. Each revision is saved as a version, and a version picker lets reviewers move between them to see what changed between iterations. This makes it possible to track how a plan evolved in response to comments, rather than only seeing the latest state.
Comments pinned to plan sections
Reviewers can leave comments pinned to a specific section of the plan, such as a particular file, step in the change sequence, or open question, instead of leaving a single general comment on the whole plan. This keeps feedback attached to the exact part of the plan it applies to, even as the plan is revised.
Mermaid diagrams
Plans can include Mermaid diagrams to describe flows, sequencing, or architecture changes. These are rendered inline in the plan view, so reviewers can follow the diagram alongside the written plan rather than reading raw diagram syntax.
Approve or request changes
A plan must be explicitly approved before implementation can start. Reviewers can:
- Approve the plan, allowing implementation to proceed
- Request changes, sending the plan back with comments attached to the relevant sections
This gate means implementation only begins once a reviewer has signed off on the approach, not just the eventual code.