{"id":48463,"plugin_id":"plugin_asdk_app_6abde61cdafc8191b1257f676fed1018","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-24T13:36:30.569Z","digest":"ba58b122cf67b8a5b61ba043599d29a5705a6624f4ac32137488b419093656bf","against":null,"payload":{"description":"Use when the user wants real-user evidence before an important product decision, UX change, launch, pricing or messaging change, or proposed action. Creates a Usercall study only after the user agrees, and returns findings from real participant interviews.","included_files":[],"name":"validate-with-users","skill_md_contents":"---\nname: validate-with-users\ndescription: Use when the user wants real-user evidence before an important product decision, UX change, launch, pricing or messaging change, or proposed action. Creates a Usercall study only after the user agrees, and returns findings from real participant interviews.\n---\n\n# Validate with users (evidence before an important assumption)\n\n## What to tell the user\n\nUse short sentences. If the user gives a direct instruction, follow it.\n\n- Real interviews come first. A practice run only checks the questions. Never present it as what users said.\n- Interviews can run up to 1 hour.\n- Interviews work in 50+ languages.\n- We can recruit participants for you, or you can bring your own.\n- They can watch interviews live as a silent observer.\n- Do not name a voice provider. Do not name a recruiting company.\n- Do not create a study until the user agrees. One study can be active. If one already exists, reuse it. Do not create a second study.\n\n## When to use\n\nLoad this skill when someone is about to make a consequential product decision based on an assumption, including:\n\n- \"Users will understand this new empty state\"\n- \"Nobody uses this step, so we can delete it\"\n- \"The summary is good enough\"\n- Internal opinion looks fine, but real users may disagree\n- A launch depends on an unverified guess about how users think\n\nPrefer this skill before shipping a hard-to-undo UX removal, a pricing change, or a default-on behavior.\n\n## Goal\n\nState the assumption clearly, interview real users with Usercall, and return evidence that supports, weakens, or replaces the assumption before the decision is locked in.\n\n## Workflow\n\n### 1. Examine the evidence\n\nWrite down:\n\n- The decision under consideration\n- The assumption in one sentence\n- What analytics or internal opinions already say\n- Cost of being wrong (harm, churn, support load, trust)\n\n### 2. Known vs unexplained\n\n- Known: decision options and current signals\n- Unexplained: whether real users share the assumption, what they expect, what they worry about\n\nIf the data already shows the assumption is wrong, say so and skip interviews.\n\n### 3. Propose Usercall when real users should weigh in\n\nExplain that Usercall can run a short interview aimed at the decision. You can show an image or a prototype so people react to a concrete design. Ask before creating the study.\n\n### 4. Identify users and event\n\nChoose the tightest relevant audience:\n\n- People who recently used the feature under change\n- People on the plan affected by the pricing copy\n- People who reached the flow you plan to change\n\nUse `list_trigger_events` and the event schema, or a list the user already has, if product events are unavailable. Do not invent an invite for people who did not do something. Invites only match an exact event.\n\n### 5. Research questions\n\nConvert the assumption into a research goal, for example:\n\n- \"Before we remove the billing guide, why do people dismiss or ignore it today?\"\n- \"How do users read this new empty state, and what do they try next?\"\n\nIf you are testing a design, include `study_media` with a public image or prototype URL. Phone participants will not see it.\n\n### 6. Approval\n\nConfirm the assumption, research goal, media (if any), interview count, and who will be invited. Findings should inform the decision. Do not create a study until the user agrees.\n\n### 7. Create study and optional invite\n\n`list_studies` → `create_study` (with media if approved) → `simulate_interview` → optional `review_study` / `update_study` → paused invite or share the link.\n\n`simulate_interview` is a practice run of the questions. Do not treat it as validation. Do not ship the gated change until real findings return, unless the user explicitly accepts that risk.\n\n### 8. Retrieve findings\n\nWhen the user says people are done, or they ask for results, call `get_study_status`, then fetch summary results. Do not sit in a poll loop.\n\n### 9. Return evidence\n\nStructure the answer as:\n\n1. Assumption tested\n2. Verdict: supported, weakened, or replaced, based only on real interviews\n3. Themes and verbatim quotes\n4. Risks or unknowns that remain\n5. Decision options grounded in that evidence\n\nIf interviews are still incomplete, say what is pending. Do not pretend the assumption is validated.\n\n## Safety and limits\n\n- Do not treat a practice run as real user validation.\n- Do not turn an invite on or message customers without the user.\n- Prefer summary results. Open a full transcript only for a needed quote.\n- If credits are short (HTTP 402), share the checkout link and stop.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}