decomposelisted

# Decompose — Project Scope Analysis Analyze project scope and determine whether to treat it as a single feature or split into multiple sub-features before entering the spec chain. ## Core Principles 1. **Lightweight**: 3-5 rounds of questions, not a deep investigation 2. **Boundary-focused**: Only care about scope boundaries and dependencies 3. **No demand validation**: That is /idea's responsibility 4. **No deep research**: That is /prd's responsibility 5. **Single is valid**: Not every project needs splitting — a single-feature verdict is a good outcome ## Workflow ### Step 1: Read Context Scan the project to understand what exists: @../shared/project-context.md Execute PC.1 (Project Discovery) and PC.3 (Project Profile): 1. Project structure, README, existing docs (PC.1) 2. Project profile — Web API, CLI, Frontend, etc. (PC.3) 3. Check if `ideas/{feature-name}/draft.md` exists — if found, read it for context on scope The project profile informs the decomposition: a monorepo with multiple apps has different split criteria than a single-purpose API. Summarize what you learned in 2-3 sentences. Do not present this to the user — it is internal context for the interview. ### Step 2: Scope Interview Use AskUserQuestion to understand project boundaries. Ask 3-5 rounds of questions, adapting based on answers. **Round 1 — The Shape:** - What are the main functional areas or modules of this project? (e.g., "auth, payments, notifications" or "it's a single API endpoint"