create-study-from-brief/SKILL.md inside your agent client’s supported skills directory. The raw file is the installable artifact; this page is its documentation wrapper.
SHA-256: f866e038b93ca2446373af1df9a6f7fac25b3288216e8f7a3fe829dc2061467d
Instructions
---
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.
allowed-tools: Read
---
When the user asks to create a study:
Apply the shared [approval and workflow continuity policy](references/approval-continuity.md).
1. Ask the human to choose Panel, BYOP (bring your own participants), or synthetic respondents when unstated. Set `recruiting_method` to `panel`, `byop`, or `synthetic_respondents` accordingly. Synthetic respondents use chat only. 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 for Panel or BYOP, and chat for synthetic respondents. 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. Prefer `queue_customize_study` with the user's natural-language brief, then poll `get_customize_study_job` until it succeeds and inspect its `result`. Use synchronous `customize_study` when sending a native concept image. Pass the 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. Use `decisions: "human"` by default. Set `decisions: "agent"` only when the person has delegated research-design choices; report returned assumptions. Relay required `questions[]` to the user and submit their answer as another planning turn. Poll each queued turn before continuing. Agent mode does not authorize a recruiting choice, plan approval, or paid launch.
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`. Plans contain Learning Goals: answerable questions with evidence requirements underneath. Do not render the derived `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. Before asking for approval, offer a practice run of the guide. By default, use no tools: review the saved plan for leading or stacked questions, clusters without a behavior anchor, and a flow that will not fit 20–30 minutes, then play two or three short example respondents to show where the conversation would stall. Head every part of it **Practice run, not findings**. Never quote it as evidence, count it in prevalence, or pass it to analysis. Only if the user asks for more, offer a separate synthetic-respondents study (`create_study` with `recruiting_method: "synthetic_respondents"`, chat only). Before creating it, say that it may use account credits and that synthetic answers are directional, not research findings. Keep it separate from the real study and never mix its results into the real study's analysis. Send any changes the user wants through `customize_study` and return the revised plan.
9. 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.
10. 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 `estimate_panel` and separate approval of its complete estimate through the launch preview and human confirmation flow.

