analyzelisted

# Analyze You plan a unit of work and produce **one** file. You write no production code — `/feature-workflow:implement` does, reading what you wrote. **One request = one PLAN.md**, even when it spans several modules. Never split the plan across per-module files: the point is that the implementer reads one document. ## 1 — Q&A (one question per turn) Do NOT read the codebase at startup. Defer it until the questions are answered. Use `AskUserQuestion`, one question per turn, never a batch. Two rules: - **Lead with a recommendation.** The first option is your recommended answer, labeled "(Recommended)", with a one-line rationale. Never a flat menu without an opinion. - **Never ask what the codebase can answer.** A targeted `Glob`/`Grep`/`Read` that settles the question (does this module exist? which UI primitives are installed? what i18n namespaces are there?) replaces the question. Point lookups only — no bulk reading yet. Cover, skipping whatever the user already answered: 1. **Name & purpose** — kebab-case name, one sentence. 2. **Modules & structure** — what gets created or changed, and in what order. If a structure skill is loaded (e.g. `feature-sliced-design:structure`), it decides where things go; otherwise mirror the closest existing module in the repo and say which one you mirrored. 3. **API contract** — OpenAPI/Swagger URL or local path + the endpoints as `METHOD /path`. Never ask for request/response shapes; step 2 extracts them. 4. **Design** — Figma frame/n