{"id":48460,"plugin_id":"plugin_asdk_app_6abde61cdafc8191b1257f676fed1018","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-24T13:36:30.536Z","digest":"c890a1dbab511d05b47cdcfed811d6f7d7114b317f7dc1c31126e80a1edcd4c2","against":null,"payload":{"description":"Use when analytics shows a behavior change, spike, drop, cohort difference, unusual path, or unexpected event and the user wants to understand why. Creates a Usercall interview study only after the user agrees, and can prepare a paused invite for the people who did it.","included_files":[],"name":"investigate-user-behavior","skill_md_contents":"---\nname: investigate-user-behavior\ndescription: Use when analytics shows a behavior change, spike, drop, cohort difference, unusual path, or unexpected event and the user wants to understand why. Creates a Usercall interview study only after the user agrees, and can prepare a paused invite for the people who did it.\n---\n\n# Investigate user behavior (ask real users why)\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 analytics (PostHog, Mixpanel, Amplitude, GA4, warehouse charts, or similar) already show a real behavioral signal, and the remaining question is why people acted this way.\n\nExamples: a cohort suddenly uses a feature more; two plans diverge on activation; power users take a surprising path; a new feature is used repeatedly without a clear success.\n\nDo not use this skill when the chart already names a tracking gap, a missing feature flag, or a pure instrumentation bug. Fix measurement first.\n\n## Goal\n\nTurn \"we see the what\" into \"here is the why,\" using interviews with real users and, when the product is instrumented, a paused invite aimed at the people who just did the behavior.\n\n## Workflow\n\n### 1. Examine the evidence\n\nCollect what is already known from analytics or logs:\n\n- Metric or event name, time window, and absolute counts or rates\n- Segment filters (plan, locale, platform, cohort)\n- Funnel or path context (what came before and after)\n- Links to dashboards or insight ids if available\n\nSummarize this for the user in plain language before proposing interviews.\n\n### 2. Separate known vs unexplained\n\nMake two lists:\n\n- Known from data: what happened, to whom, when, how often\n- Still unexplained: motivations, confusion, competing goals, what got in the way, workaround stories\n\nIf \"unexplained\" is empty, stop. Do not invent a Usercall study.\n\n### 3. Propose Usercall when the human why is needed\n\nIf the why is still open, explain that Usercall can:\n\n1. Create an interview study from a research question\n2. Optionally prepare an invite for people who fire a matching product event (it stays off until a person turns it on)\n3. Return themes, risks, and verbatim quotes\n\nAsk before creating anything that spends credits or invites users.\n\n### 4. Identify users and event\n\nPrefer in-product targeting when the Usercall snippet is live:\n\n1. Call `list_trigger_events`\n2. If empty, call `get_trigger_sdk_setup` (provider and event names) and help install or show the snippet\n3. Call `get_trigger_capabilities` so you do not invent unsupported filters\n4. Call `get_trigger_event_schema` for the chosen event before setting properties or traits\n\nIf product events are not available yet, plan to share `interview_link` manually (email, Slack, support, or a customer list) after the practice run and review.\n\n### 5. Draft research questions\n\nWrite a sharp `key_research_goal` (plain language, 5 to 2000 characters), for example:\n\n- \"Why did recently activated teams invite fewer teammates after the first project?\"\n\nOptional `business_context`: product, metric, window, counts, who to interview.\n\nPropose 3 to 5 probes the guide should cover. Prefer open \"why\" and \"what were you trying to do\" questions over leading ones.\n\n### 6. Get approval\n\nBefore calling write tools, confirm with the user:\n\n- Research goal and context\n- Target interview count and mode (voice or text)\n- Whether to use an in-product invite or a link they share\n- Event name and filters (exact match only)\n- Sampling, cooldown, and daily invite caps if using an invite\n\nDo not create a study until the user agrees.\n\n### 7. Create the study and optional invite\n\n1. `list_studies`. Reuse one if an open study already asks this question.\n2. `create_study` with the approved goal (and context).\n3. `simulate_interview` (start, then read with `simulation_id`) until it passes, or fix the guide with `update_study` and try again (max 5 practice runs per UTC day). Omit `persona` unless a specific one is required. A finished transcript is role and content only. This is a practice run, not findings.\n4. Optional: `review_study`. Send `suggested_edits` to `update_study` as-is, or skip it when it is null. Nothing is applied for you.\n5. If targeting in product: `create_research_trigger` (always paused). Hand the activation link to the user. Do not turn it on.\n6. If manual: give the user `interview_link` (`https://app.usercall.co/interview/...`) only when a practice run or review is finished, completed interviews are still 0, and any review edits are already on the guide.\n\nNever say the invite is live until a person has turned it on.\n\n### 8. Retrieve findings\n\n1. When the user says people are done, or they ask for results, call `get_study_status`. Zero interviews is `not_started`. `running` means an interview is underway. Do not sit in a poll loop. Do not treat `running` or `analyzing` as findings.\n2. When status is complete, call `get_study_results` with `format=summary` (use `full` only if a transcript quote is required).\n\n### 9. Return evidence\n\nPresent:\n\n- Original metric or behavior summary (the what)\n- Themes with verbatim quotes\n- Key insights and risks or unknowns\n- Study id, completed vs target interviews\n- Whether an invite is still off or on\n\nStop when the summary answers why. Do not pad with guesses beyond the evidence.\n\n## Safety and limits\n\n- Do not turn an invite on, and do not message participants for the user.\n- Unsupported invite conditions (counts, sequences, absence, time windows, not-equals) must be refused, not approximated.\n- One study can be active. Do not create a second study.\n- Delete tools are permanent. Prefer disabling a link over deleting evidence.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}