Skills Library

---
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:

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, use `list_available_modes` or `list_available_languages` for discovery. The public voice override is `male` (Elliot) or `female` (Clara); provider-specific IDs from `list_voices` are not accepted. Never supply `voice` for chat.
3. Use `list_study_types` only when the user needs help choosing a type. Do not draft a plan from its prompts; 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 its audience, screeners, concepts, interview settings, and `provisioning_status`. Do not replace it with a summary or dashboard link.
8. Ask the user to approve that exact plan version or request revisions. Send revisions through `customize_study`, fetch the study again, and repeat the complete review. 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.

---
name: design-screeners
description: Use when the user wants to screen participants, define qualification criteria, or target a Panel study.
---

When the user asks to change screening:

1. Call `get_study` before writing. If a Panel study is fielding, ask whether to `pause_study` or `stop_study` before editing.
2. Call `customize_study` with the user's audience or screening request in ordinary language. Do not create targeting IDs or screener schemas yourself.
3. Let Customize Plan match standard criteria such as age or household income to canonical targeting attributes. It should use custom screeners only where appropriate.
4. If it returns `response_type: "question"`, relay the question and send the user's answer back through `customize_study`. Never answer on their behalf.
5. Never add recording-consent or willingness-to-participate questions. Do not add screening the user did not request.
6. Call `get_study` and return the complete revised plan in a readable form together with persisted targeting, screeners, concepts, settings, and likely recruitment tradeoffs.
7. Ask the user to approve that exact revised plan version. An approval given before the screening change no longer covers the study.
8. If the study was paused and recruitment should continue, call `resume_study` only after the update is verified and the revised plan is approved.

---
name: field-a-panel
description: Use when the user wants to estimate, launch, pause, resume, or stop recruitment for a User Intuition Panel study.
---

When the user wants to field a Panel:

1. Call `get_study` and verify `recruiting_method` is `panel` and `provisioning_status` is `provisioned`.
2. Return the complete current `study_plan` in a readable form together with its audience, screeners, concepts, and interview settings. Obtain explicit approval of that exact plan version before a paid launch; approval of study creation, a prior plan, or the cost estimate does not count.
3. Ask the user to choose one launch country explicitly. Never infer a country from language, location, account data, or a broad region. Each launch fields exactly one country; multi-country work requires separately reviewed country-specific studies or launches.
4. Call `list_panel_countries` to verify that the chosen country supports the study language.
5. If targeting is requested or needs to change, use `customize_study`, complete any questions with the user, then call `get_study`, return the complete revised plan, and obtain approval of the revised version.
6. If `incident_rate` is below 10 or the audience is unusually specialized, use `submit_feasibility_request` instead of direct launch.
7. Always call `launch_panel` with the explicit `country_code` and `dry_run: true` first. Show the resolved country, language, target, incident rate, estimated cost, and timeline.
8. Wait for explicit approval of that complete estimate. Never infer approval from the original request, plan approval, or client permission settings, and never silently switch `dry_run` to false.
9. After approval, repeat `launch_panel` with `dry_run: false` and the same settings and country. Report what was launched.
10. Use `pause_study` to preserve progress and the reward hold, `resume_study` to continue, and `stop_study` to end recruitment and settle or release the hold. Confirm before stopping.

---
name: invite-your-own-participants
description: Use when the user wants to add, invite, update, or reward their own participants in a BYOP study.
---

When the user supplies participants:

1. Call `get_study` and verify `recruiting_method` is `byop` and `provisioning_status` is `provisioned`.
2. Return the complete current persisted study plan in a readable form with its audience, screeners, concepts, and interview settings. Obtain explicit approval of that exact version before creating participants; approval to create or customize the study does not count.
3. Normalize and deduplicate email addresses case-insensitively. `create_participants` accepts 1–100 participants per request.
4. Explain that invitations send by default. Use `silent: true` for each participant when the user wants records created without sending email.
5. Call `create_participants` with `study_id` and the batch only after provisioning and exact-version plan approval are confirmed.
6. Use `list_participants` to verify the batch. Call `get_participant` before `update_participant`.
7. `send_participant_reward` has a financial side effect and is BYOP-only. Confirm the exact participant and require an explicit request before sending. The backend prevents a duplicate reward for an already-paid participant.
8. Participant deletion is not available through the public MCP surface. Do not promise to delete a participant.

---
name: run-a-concept-test
description: Use when the user wants participants to react to a concept, prototype, design, or landing page during a User Intuition interview.
---

When the user wants a concept test:

1. Follow the create-study-from-brief workflow and choose the correct metadata type. Use `study_type: "concept-test"` for a participant-facing concept image or non-interactive concept. Use `study_type: "prototype-test"` for a clickable prototype, staging site, live page, or web flow.
2. A concept image can use chat, voice, or video. A concept link cannot use chat: relay the backend's question and let the user choose voice or video rather than choosing for them. A prototype test also cannot use chat; use the default voice format or an explicitly requested video format.
3. Call `customize_study` with the user's goal and requested link or image. For a prototype include its URL, participant-facing label, intended tasks, audience, and learning goals. Let the backend structure the flow, check the asset, and reconcile it with the plan.
4. For an image whose bytes or readable local path are available, base64-encode the raw file and pass `concept_image` with its filename, MIME type, and the user's participant-facing label. Otherwise, a public downloadable URL and stable label can be sent in the message. If the client exposes only an opaque attachment reference, explain that client limitation and offer the available upload routes.
5. Relay every `response_type: "question"` to the user, including mode or asset confirmations, and send their answer back unchanged.
6. Call `get_study`, return the complete persisted plan and concept configuration, and obtain approval of that exact version. Never request credentials or promise that a login-protected URL can be used.
7. Field through the Panel or BYOP Skill only after provisioning and current-plan approval. Dry-run Panel cost and require separate confirmation before launch.

---
name: monitor-fielding
description: Use when the user wants a read-only status snapshot of User Intuition studies or interviews.
---

When the user asks for fielding status:

1. Call `list_studies`, paginating when necessary. Use response totals rather than counting only the current page.
2. For each study in scope, call `list_interviews` with its `study_id`. Use `status` and `quality` filters when the user asks for a breakdown.
3. Present a compact table with study name, recruiting method, lifecycle status, interview count, and quality distribution when available.
4. Flag stalled recruitment, no completions, or a high Fair/Poor share as observations, not diagnoses.
5. Keep the workflow read-only. Offer `pause_study`, `resume_study`, `stop_study`, or report generation as follow-ups, but do not mutate unless the user explicitly asks.

---
name: analyze-completed-study
description: Use when the user wants findings, themes, evidence, or a report from completed User Intuition interviews.
---

When the user asks for analysis:

1. Identify the study with `list_studies`; disambiguate similar names. Call `get_study` for full context.
2. Call `list_interviews` with the `study_id` and check whether enough completed, usable interviews exist. Say when evidence is still thin.
3. Call `get_study_report`. If no report exists or it is stale and the user asked for fresh analysis, call `generate_report`, then fetch the report again.
4. For load-bearing findings, call `get_interview` on the supporting interview IDs and verify evidence in the returned messages. Never invent quotes or attribute a claim to an interview you did not fetch.
5. Summarize the headline, 3–5 themes, participant counts when supported, evidence, contradictions, and open questions.
6. Distinguish direct evidence from inference. Offer a follow-up study when the biggest uncertainty cannot be answered from the current interviews.

---
name: curate-interview-quality
description: Use when the user wants to review interview quality or explicitly delete unusable interviews from one User Intuition study.
---

When the user asks to curate quality:

1. Identify one study and call `list_interviews` with its `study_id`. Use the `quality` filter for Excellent, Good, Fair, or Poor subsets.
2. Fetch each interview under review with `get_interview`. Summarize why it may be low quality using only the returned messages and metadata.
3. Recommend an action, then wait. The current MCP surface does not provide `update_interview`, hide, or quality-override operations.
4. Call `delete_interview` only when the user explicitly confirms the exact interview ID. Never bulk-delete from a quality filter without per-study, clearly scoped confirmation.
5. Re-run `list_interviews` and report the after-state. Explain if the remaining usable sample is too small for reliable analysis.