decompose

# 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**: a brief interview, not a deep investigation — ask only what you cannot already infer 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). Prefer the fast path — resolve `<sf_scripts>` (see `@../shared/scripts.md`) and run `python3 "<sf_scripts>/sf-scan.py" --root "<project_root>"`, which returns the project structure, languages, frameworks, DB/auth signals, and the existing-doc inventory in one pass. Fall back to the manual PC.1/PC.3 scan only if `python3` is unavailable or the script is not found — switch to the fallback silently. 1. Project structure, README, existing docs (PC.1) — read from the scan's document inventory and source-tree fields 2. Project profile — Web API, CLI, Frontend, etc. (PC.3) — the scan gives the raw signals; you label the profile 3. Check if `ideas/{feature-name}/draft.md` exists — if found, read it for context on scope ...