forge-planlisted

# Forge Plan This is the planning step in the issue pipeline: `clarified → approved` (it runs after triage and clarify). Its job is to turn a triaged, reproduced issue into a concrete implementation plan that a coding agent (or developer) can follow without re-exploring the codebase. Planning is the highest-value step in the pipeline. A good plan saves the coding step from wasting tokens on exploration, wrong turns, and rework. A bad plan (or no plan) means the coding agent explores blindly, makes architectural mistakes, and produces code that needs heavy review. ## Usage ``` /forge-plan <documentId> ``` ## Tools `forge_issues`, `forge_comments`, plus codebase exploration tools (Read, Glob, Grep). ## Two-Tier Planning Not every issue needs deep codebase exploration. The planning depth should match the complexity: **Lightweight plan (xs/s/m):** Use project knowledge (`forge_knowledge`) + issue description + targeted Glob to identify files and write the plan. Read at most 1-2 source files — only when you need to check an existing pattern or verify a component's current props/API. The coding agent will read the files during implementation anyway, so duplicate deep-reading wastes tokens. **Deep plan (l/xl):** Full codebase exploration. Read all affected files, trace dependencies, verify patterns. `l`/`xl` issues involve architectural decisions where a wrong plan costs more than the exploration. The tier is determined by the triage comment's complexity classification.