planlisted

# Plan Turn the request into one build-ready Markdown task artefact. An explicit plan or design request stops after the file is reviewed. Do not ask where to build and do not implement. If the same request explicitly includes building, return control to `dispatch` after the file is ready without another confirmation. ## 1. Inspect and classify Read project instructions, repository state, relevant code, nearby tests, and only directly relevant project memory. Then choose: - **Direct:** clear, reversible, one subsystem. Coordinator plans; zero child calls. - **Focused:** moderate scope or several related tasks. A plan-only request may use one investigator and one separate reviewer; maximum two planning child calls. - **Deep:** security, migration, cross-boundary architecture, or material research. A plan-only request may use two or three independent investigators, one planner synthesis, and one specialist review; maximum five planning child calls. | Plan lane | Child-call ceiling | Planning-token ceiling | |---|---:|---:| | Focused | <=2 child calls | <=6k planning tokens | | Deep | <=5 child calls | <=18k planning tokens | The call ceilings are hard. Token ceilings are host-reported budgets; never invent usage when the host does not expose it. Questions come after inspection and only when an answer changes the plan materially. Prefer a documented, reversible assumption. Ask no more than three concise questions in one turn. ## 2. Investigate economically Give each chil