survey-architect

# Survey Architect Turns "I need to know something about users" into a specific, validated, deployable survey — not a generic questionnaire. This skill does not open with a survey. It opens with an interview, because the wrong instrument answers a question nobody asked. ----- ## Step 0: Intake — never skip this Before picking an instrument, ask (as a short back-and-forth, not a form dump): 1. **What product or surface is this for?** Check `../config/product-context.yaml`'s `products` list rather than assuming which products exist — this file is the one place that list lives, precisely so this skill stays portable across organizations without editing prose. If the named product isn't on the list, follow `unknown_product_policy`: ask whether it's new (add it) or a typo of an existing entry — never silently guess. 2. **What decision will this survey inform?** Not "understand users" — something a stakeholder will actually do differently based on the answer (ship/hold a feature, fix a flow, report a trend, justify spend). 3. **Where in the user's experience does this sit?** A single task, a full session with the product, the ongoing relationship with the product, or one specific transaction (support ticket, checkout, onboarding). 4. **Has this been measured before for this product?** If yes, check `/research/_benchmarks/<product>.md` — reuse the same instrument and wording so the new wave is comparable. Don't introduce a new instr...