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

Planning starts from a coding agent with the Baz plugin installed:

/baz:plan-with-baz

The command kicks off a planning run scoped to the task at hand. The agent explores the relevant repositories, including ones you have never cloned, before producing a plan, rather than proposing changes from the prompt alone.

Pulling comments back into the CLI

Run /baz:get-plan-comments in Claude Code, get-plan-comments in Codex, or /get-plan-comments in Cursor, from the same session that owns the plan, to bring every comment back into the terminal and update your plan accordingly.

What a plan captures

Surfacing this before implementation turns architectural and sequencing decisions into something reviewers can weigh in on, instead of discovering them after the fact in a diff.

Plans workspace

Every plan lives in the Plans workspace, which lists plans across repositories with their current status, so it is clear which are awaiting review, approved, or already in implementation. Opening a plan shows its sections, affected files, and open questions. The workspace is the entry point for reviewers, not just for the person who requested the plan.

Reviewing and approving a plan

Plan review works like code review, but it happens before the code exists.

A plan can be revised after feedback, and each revision is saved as a version. A version picker moves between versions to show what changed between iterations, so reviewers can follow how a plan evolved in response to comments rather than only seeing its latest state.

Comments are pinned to a specific section of the plan, such as a particular file, a step in the change sequence, or an open question, instead of landing as one general comment on the whole plan. Feedback stays attached to the part of the plan it applies to, even as the plan is revised.

Plans can include Mermaid diagrams to describe flows, sequencing, or architecture changes. These render inline in the plan view, so reviewers follow the diagram alongside the written plan rather than reading raw diagram syntax.

A plan must be explicitly approved before implementation starts. Approving it allows implementation to proceed, and requesting changes sends 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 on the eventual code.

Tracking a planning run

Each planning run is recorded as a session, so the steps behind a plan stay inspectable: the context that was assembled, the requirements that were mapped, the risk gate that ran, and the revisions that followed review. See Sessions for how to read a planning session.

FAQ