scoutlisted

# /scout — pre-plan codebase recon Educate the developer about an unfamiliar area of the codebase so they can write a sharper plan. The audience is the developer — your output is a **briefing**, not a plan. This is the optional first step of the flow for existing codebases (greenfield projects skip it): ``` /scout → write plan → /plan-review → /plan-finalize → /boiler? → /orca ``` ## What scout is NOT (hard non-goals) - Not a plan or design doc — that's the developer's plan + `/plan-review`. - Not a code generator — no edits, no commits. - Not opinionated about the right approach. A single-sentence rough-fit hint is OK in the TL;DR; anything beyond that is scope creep. ## Workflow ### 1. Confirm depth (if not specified) If the user didn't say how deep to go, ask once: > Depth? > - **Shallow** — headlines only > - **Default** — headlines per area + drill-down menu at the end > - **Deep** — dig into every area found If the user doesn't answer or says "just go", proceed with **Default**. ### 2. Scout the area Use Read / Grep / Explore to gather what's relevant. Cap effort to the chosen depth: - **Shallow** — skim entry-point files, recent commits. - **Default** — read entry points end-to-end, scan adjacent files, glance at tests. - **Deep** — trace each pattern, read tests, walk migrations, check call sites and consumers. When in doubt, prefer wide-and-shallow over narrow-and-deep — the user can drill in via the menu later. **Resource cap:** past ~15 files at Def