plan-with-baz

Plan with Baz

You were invoked explicitly to plan a piece of work using Baz's indexed search. The work to plan is in $ARGUMENTS (if empty, ask the user what they want to plan).

This is a read-only procedure. Do not edit project files, run mutating commands, or start implementing until the user approves the plan. The only write allowed before approval is the plan document itself (see Step 2).

Step 1: Explore with Baz

Load and follow the baz-codebase-exploration skill for every search, read, and planning decision in this run. It is the authoritative source for tool routing, the search budget, the builder-vs-proxy and verify-before-you-assert checks, and the "enumerate an existing peer's registration sites" completeness rule. Invoke it now (via the Skill tool on Claude Code; on Cursor it is already applied as an always-on rule) and treat its rules as binding. This wrapper owns only the wrapper concerns — the plan-document schema and baz session close (Step 2), approval (Step 3), and the upload offer (Step 4).

If for any reason that skill is not in your context, these non-negotiables still apply — but prefer the full skill:

Job	Tool
Find which repos are involved	repo_search (Baz)
Find code by symbol / regex inside a repo	remote_grep (Baz)
Find files by name / glob inside a repo	remote_file_search (Baz)
Read one file whose path you already know	your read tool — local Read if checked out, otherwise your own fetch

• All searching goes through Baz — never list, walk, or grep a repo with your read or shell tool. Recursive tree fetches or ls/find to "look around" are searches; route them through remote_file_search / remote_grep. Your read tool is only for opening one already-known file path.
• Search budget (hard): call repo_search once and don't rephrase keywords; after 3 searches on the same (repository, path) pair, read a matched file before searching that pair again; use at most 10 searches total for the whole run — all repos and paths combined, and hopping to a new pair does not reset the count.
• Adding one more case to an existing set (another enum value, another implementation of an interface, another branch in a dispatcher): before finalizing, run ONE repo-wide search for the identifier of an existing peer already in that set. Its hits enumerate every site the set is wired through — the enum / constant list, factory or lookup maps, switch / match arms, dispatch or handler tables, route tables, and config — and your plan must add the new case at each. Skim that peer's tests too, in case an assertion that your case is absent needs updating.