Update to Usercall: User Interviews

{
  "description": "Use when the user wants to understand why people abandon onboarding, churn, bounce, retry, fail checkout, get stuck, or hit another product-friction point. Creates a targeted AI-moderated interview study only after the user agrees, and returns findings with verbatim quotes.",
  "included_files": [],
  "name": "investigate-product-friction",
  "skill_md_contents": "---\nname: investigate-product-friction\ndescription: Use when the user wants to understand why people abandon onboarding, churn, bounce, retry, fail checkout, get stuck, or hit another product-friction point. Creates a targeted AI-moderated interview study only after the user agrees, and returns findings with verbatim quotes.\n---\n\n# Investigate product friction (abandon, retry, fail, churn)\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 the product shows friction signals such as:\n\n- Funnel abandon or drop-off\n- Repeated retries or regenerations\n- Hard failures, timeouts, permission errors\n- Churn, cancel, downgrade, or silence after a bad moment\n- Unexpected UI loops or dead ends\n\nUse it when you know where friction happens but not why people stopped, retried, or left.\n\nDo not use it as a substitute for fixing a confirmed crash or a clear bug with a stack trace. Ship the fix. Interview if you still need the story around that moment.\n\n## Goal\n\nInterview people who experienced the friction. Return themes and verbatim quotes that explain blockers, misconceptions, and workarounds, so the team can act on evidence rather than guesses.\n\n## Workflow\n\n### 1. Examine the evidence\n\nGather:\n\n- Friction point (step, screen, API, feature)\n- Event or error names, rates, and severity\n- Session replay or path notes if available\n- Who is affected (segment, plan, locale, device)\n\n### 2. Known vs unexplained\n\n- Known: where and how often friction occurs\n- Unexplained: user intent at that moment, confusion, trust, price perception, missing info, competing tools, how it felt\n\nIf the unexplained list is empty, stop.\n\n### 3. Propose Usercall if the human why is still open\n\nExplain that Usercall can create an interview tied to that moment, and can prepare an invite that stays off until a person turns it on. Ask before spending credits or inviting users.\n\n### 4. Identify users and event\n\n1. Map friction to an observed event (`list_trigger_events`, then schema)\n2. If the event is missing, use `get_trigger_sdk_setup` and help install the snippet\n3. Check `get_trigger_capabilities` before proposing filters\n4. Prefer exact property or trait matches that isolate the friction (for example plan, error code, surface)\n\nIf you cannot target inside the product yet, plan a manual share of `interview_link` after the practice run.\n\n### 5. Research questions\n\nDraft a friction-focused goal, for example:\n\n- \"Why do users abandon checkout after adding a teammate seat?\"\n- \"What were people trying to finish when they hit permission denied on export?\"\n\nKeep probes about intent, expectation, and what would have helped. Avoid blaming wording.\n\n### 6. Approval\n\nConfirm the research goal, interview count and mode, targeting (in-product invite or a link they share), and sampling. Do not create a study until the user agrees. If an invite is created, a person opens the link to turn it on.\n\n### 7. Create study and trigger\n\nFollow the same safe order as other Usercall skills:\n\n`list_studies` → `create_study` → `simulate_interview` → optional `review_study` / `update_study` → paused invite or share `interview_link`.\n\n`simulate_interview` is a practice run. Do not present it as findings. Do not sit in a poll loop waiting for real interviews.\n\n### 8. Retrieve findings\n\nWhen the user says people are done, or they ask for results, call `get_study_status`, then `get_study_results` (summary). Do not sit in a poll loop.\n\n### 9. Return evidence\n\nReturn the friction context, themes, verbatim quotes, and risks. Call out anything that looks like a product bug versus a comprehension or incentive problem. Recommend a next step only when a quote supports it.\n\n## Safety and limits\n\nSame as investigate-user-behavior: no turning an invite on, no invented filters, no treating in-progress results as findings, and no delete unless the user clearly asks.\n"
}