Create study from brief

---
name: create-study-from-brief
description: Use when the user wants to create a User Intuition interview study from a brief, goal, problem, or research idea.
---

When the user asks to create a study:

Apply the shared [approval and workflow continuity policy](../../references/approval-continuity.md).

1. Ask Panel versus BYOP when unstated. Set `recruiting_method` to `panel` when User Intuition should recruit, or `byop` when the user supplies participants. Never guess.
2. Keep the name to 40 characters. Unless the user requests an override, omit `interview_format`, `language`, and `voice` so `create_study` applies the current defaults: a voice interview in English with Elliot. If the user requests another mode or language, read `userintuition://catalog/modes` or `userintuition://catalog/languages` for discovery. The public voice override is `male` (Elliot) or `female` (Clara), including for chat; implementation IDs are not accepted. If the client cannot read MCP resources, use the public API reference for valid settings.
3. Read `userintuition://catalog/study-types` only when the user needs help choosing a type. Do not draft a plan from its metadata; the backend applies the selected type's current Customize Plan instructions.
4. Call `create_study` with ordinary metadata only.
5. Call `customize_study` with the user's natural-language brief, including their audience, screening needs, and requested concept links or images. Do not construct a plan, targeting attributes, screeners, duration, or concept objects in the MCP host.
6. If `response_type` is `question`, relay the question to the user and call `customize_study` again with their answer. Never decide for them.
7. When customization completes, call `get_study`. Return the complete persisted study plan in a readable form together with available audience, screener, concept, and interview settings and `provisioning_status`. New plans contain Learning Goals: answerable questions with evidence requirements underneath. Do not render the derived legacy `key_questions` field as a second list. Intended perspectives remain unverified until compared with actual participant evidence; recruitment configuration is not required to finish the plan. Do not replace the plan with a summary or dashboard link.
8. Ask the user to approve that exact plan version or request revisions. On approval, retain the shared checkpoint. Send revisions through `customize_study`, fetch the study again, and repeat the complete review. If the returned marker changes, invalidate the checkpoint; approval of an earlier version does not cover a revised plan.
9. Verify `provisioning_status` is `provisioned` before fielding. Return the study ID and, when present, both `dashboard_url` and `study_link`; label `study_link` as the live participant interview link, not a preview. Never create BYOP participants or launch a paid Panel without current-plan approval. Panel launch also requires a dry-run and separate approval of its complete estimate.