analyze

# /supergraph:analyze Analyze first, implement never. No code until approach is approved. Announce: "🔍 /supergraph:analyze — framing problem, checking graph risk..." ## When - Ambiguous requirements - Multiple valid approaches - Task spans modules - Graph shows high blast-risk (hub/bridge nodes) - User says "how should I..." or "what's the best way..." Skip for: typo fixes, config changes, clear mechanical edits. ## Workflow **0. Read CONTEXT.md (if exists):** ```bash cat CONTEXT.md 2>/dev/null | head -60 ``` Use existing domain vocabulary in all analysis — never invent new terms for concepts already named. **1. Frame the problem:** - Goal: [one sentence] - Known constraints - Open questions ## Ceremony Router For work that enters analyze, classify the uncertainty before choosing an approach: - **spike:** the approach or feasibility is unknown. Produce a bounded experiment, define what evidence would invalidate it, and exit with a decision or an explicit escalation. - **bounded:** the behavior and boundary are known but implementation choices remain. Compare the smallest viable approaches, identify affected paths, and exit with an approved implementation shape. - **architectural:** the change crosses contracts, hubs, bridges, persistence, or multiple platforms. Produce the full graph-informed analysis and required SDD inputs before planning. Approval required before implementation on every path. The router may skip unnecessary ceremony, but it may not skip approv...