Affected repos and files
Every repository and file the change is expected to touch, resolved before anyone opens an editor.
Don’t review the wrong code
Baz Planner steers coding agents away from bugs and vulnerabilities before code exists. It finds the services, dependencies, and conventions a change touches, then makes the approved plan the source of truth for implementation.
/plugin marketplace add baz-scm/baz-plugin
/plugin add baz
/reload-pluginsInstall the Baz plugin, then start a planning session: /baz:plan-with-baz in Claude Code, the plan-with-baz skill in Codex, /plan-with-baz in Cursor. All three connect to the hosted Baz MCP server at https://baz.co/mcp over OAuth.
The most expensive bugs are approved by the plan.
They aren’t missed at review. A vague ticket becomes almost-right code, then engineers spend cycles fixing the approach after the work is done. Planner reviews the approach first, so the fix costs a plan edit, not a rework cycle.
Review the approach before anyone builds it
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 a human can read, question, and approve.
Plans against code you never cloned
Planner searches an index of every repository in your organization, so the plan accounts for the caller in another service and the convention your team already set, not just the repo you have checked out.
Approval is a gate, not a formality
A plan has to be approved before implementation starts. Reviewers approve, or request changes with comments pinned to the exact step or open question they apply to.
Review as confirmation
When the plan is right, the pull request is a sanity check. Reviewers confirm the approach they already approved instead of correcting it.
Result The mistake that would have cost a rework cycle costs a plan edit instead.
What a plan says, and how it gets approved
A planning session starts from your coding agent, with the planning command the plugin installs there. The agent gathers context from the relevant repositories first, then writes a plan that reads like a design review: the same sections every time, reviewable section by section. See the Planner docs for the full record.
Change sequence and cross-repo coordination
The order operations happen in, including dependent steps, and how changes across multiple repositories need to line up with each other.
Open questions
The ambiguities and decisions that need an answer before implementation, called out instead of guessed at.
Verification steps
How the change should be tested or validated once it is implemented, agreed on before the code exists.
Versions, pinned comments, diagrams
Each revision is saved as a version, and a version picker shows what changed between iterations. Comments stay attached to the section they apply to, and Mermaid diagrams render inline in the plan view.
The Plans workspace
Every plan across every repository, with its status: awaiting review, approved, or already in implementation. It is the entry point for reviewers, not just the person who asked for the plan.
What is rework costing you?
Half of all pull requests enter a fix-and-review loop after review starts, and every loop is work paid for after the code exists. Estimate the tax on your team, then see what Planner recovers by catching the same issues in the plan.
Rework tax estimator
Price the loop, then shift it left
Set your volume and cost. See what post-review correction loops run you today, and how much Planner recovers by catching the same issues in the plan.
2,500
Fully loaded engineering cost$150/hr
Estimated impact
Rework tax$255K/moextra review passes + active blocked-cycle time
Recovered with Planner$89.2K/mo~35% of rework shifted upstream, before code exists
Recovered with PlannerRemaining tax
Baz platform baseline: 50.2% of PRs enter a post-review rework loop, measured across 59,860 PRs. Planner impact holds the full calculator’s 35% default, tunable there.
Catch it in the plan, not the pull request.
Post-coding reviewShift left with Planner
Vague ticket, straight to codingDesign review and a buildable plan first
Problems surface after the code is writtenEntire classes of problems never get written
Heavy correction loop inside the PRLightweight confirmation at review
Fix, re-review, fix againRight-first-time delivery
Pay for the work, the rework, and the context switchingPay for the work once
Stop paying the rework tax.
We’ll run Planner against a real change from your backlog and show you what it catches before a line of code exists. On the estimate above, catching those issues in the plan shifts about 35% of the rework tax upstream.