Update to Rippit

{
  "description": "Detect brewing escalations in a Rippit customer's support tickets — conversations at risk of turning into legal action, a public/social-media blow-up, or an exec/board complaint — and deliver the top examples as a ready-to-post Slack update. Use this whenever the user asks to find, surface, monitor, or get ahead of escalations, \"brewing\" or \"at-risk\" or \"about-to-blow-up\" tickets, churn threats, legal/PR/exec risk in support, or wants a recurring escalation digest posted to Slack. Trigger even if the user only says something like \"what support issues are about to blow up on us?\" or \"set up an escalation watch for a specific account\". This runs against the Rippit MCP toolchain (list_data_sources, describe_table, create_worksheet, enrich_worksheet, get_enrich_status, then aggregate/read), so prefer it over ad-hoc querying for any escalation-detection request.",
  "included_files": [],
  "name": "rippit-escalation-finder",
  "skill_md_contents": "---\nname: rippit-escalation-finder\ndescription: >-\n  Detect brewing escalations in a Rippit customer's support tickets — conversations\n  at risk of turning into legal action, a public/social-media blow-up, or an exec/board\n  complaint — and deliver the top examples as a ready-to-post Slack update. Use this\n  whenever the user asks to find, surface, monitor, or get ahead of escalations,\n  \"brewing\" or \"at-risk\" or \"about-to-blow-up\" tickets, churn threats, legal/PR/exec\n  risk in support, or wants a recurring escalation digest posted to Slack. Trigger even\n  if the user only says something like \"what support issues are about to blow up on us?\"\n  or \"set up an escalation watch for a specific account\". This runs against the Rippit MCP\n  toolchain (list_data_sources, describe_table, create_worksheet, enrich_worksheet,\n  get_enrich_status, then aggregate/read), so prefer it over ad-hoc querying for any\n  escalation-detection request.\n---\n\n# Escalation Radar\n\nSurface support conversations that are quietly turning into escalations — legal exposure,\na social-media flare-up, or a complaint headed for an executive's inbox — before they do.\nThe output is a tight, ranked Slack post of the most pressing examples, plus an optional\nrecurring automation.\n\nThe core idea: **the data already knows which tickets are unresolved and noisy; what it\ndoesn't know is which ones carry real escalation risk for *this specific company right\nnow*.** A web search grounds the run in what's currently combustible for the customer\n(recent outages, regulatory heat, public complaints), and a fresh enrichment pass scores\neach conversation against those vectors. Don't trust pre-existing \"churn risk\" style\ncolumns to do this — they're inconsistent across customers and weren't built for this\nquestion. Build the judgment fresh.\n\n## When NOT to over-engineer\n\nIf the user just wants a count or a simple distribution (\"how many unresolved tickets this\nweek\"), that's a plain `aggregate_table` call, not this skill. This skill earns its weight\nwhen the user wants *which specific conversations are dangerous and why* — a ranked,\nhuman-readable shortlist with evidence.\n\n---\n\n## Workflow\n\nRun these in order. Confirm with the user at the two marked checkpoints — don't barrel\nthrough them, because a wrong status filter or a wrong company guess silently corrupts\neverything downstream.\n\n### Step 1 — Identify the customer (the company whose tickets these are)\n\nCall `list_data_sources`. In the common case there is one obvious support-cases table; use\nit. If several tables exist, pick the one that holds support conversations (look for\ncolumns like contact reason, status, sentiment, conversation summary) and, if it's\ngenuinely ambiguous, ask the user which table.\n\nDetermine **which company this data belongs to** — i.e. the Rippit customer. This is NOT a\nper-row \"requester's employer\"; every row is the customer's own support traffic. Infer the\ncompany from the table name and from `describe_table` content — product-area values, case\norigins, and competitor mentions usually name the company outright (e.g. product areas like\n\"[Fintech Company] Card\", \"[Fintech Company] Dashboard\" → the company is that Fintech\nCompany). If you cannot infer it confidently,\nask the user: \"Which company's support data is this?\"\n\n### Step 2 — Ground the run in the company's current risk surface (web search)\n\nWeb-search the company for **recent, specific** escalation fuel — not a generic industry\nlecture. Aim 4–8 searches at things that would make a support ticket more likely to\nescalate *this month*:\n\n- recent outages, incidents, or degraded-service reports\n- regulatory actions, investigations, lawsuits, or compliance scrutiny\n- public complaints, viral threads, BBB/Trustpilot/Reddit/X flare-ups, press\n- anything sector-specific that raises the stakes of a mishandled ticket (for a fintech:\n  frozen funds, account closures, fraud liability, KYC lockouts; for a marketplace:\n  refunds, safety; etc.)\n\nSynthesize this into a short list of **escalation vectors** that are live for this company\nright now. You'll feed these into the enrichment in Step 5. Keep the synthesis honest: if\nthe search turns up little, say so and fall back to generic high-severity vectors (legal\nthreat, public/social threat, executive escalation, regulatory) rather than inventing\ncompany-specific drama.\n\n### Step 3 — Read the schema and choose two raw columns\n\nCall `describe_table`. From the raw table you only need **two** columns (everything else\nabout escalation gets enriched fresh):\n\n1. **A signal-strength / interest column**, if one exists — something that flags whether a\n   conversation is substantive vs. noise (e.g. an \"Interest Level\" column with values like\n   low / moderate / high / very high / ignore). Use it to drop noise before enriching, so\n   you don't pay to score auto-replies and empty tickets. If no such column exists, skip\n   this filter.\n2. **A status column** indicating whether the issue is open/closed/solved/pending/etc.\n   Identify its distinct values.\n\nAlso note the **recency column** (a last-activity / last-seen / updated datetime) for the\n7-day window, and the **id columns** (`ticket_sid` / `external_id`) for later quoting via\n`read_conversations`.\n\n### Step 4 — CHECKPOINT 1: confirm the unresolved filter, then build the worksheet\n\n\"Unresolved\" varies by customer, so confirm before filtering. Default definition:\n\n- **status NOT in the closed set** — closed/solved/merged and their variants (e.g. \"Closed\",\n  \"Solved\", \"Merged\", \"Closed - No Action Required\", \"Solved - No Response From Customer\").\n  List the exact statuses you're treating as resolved and ask the user to confirm or adjust.\n- **recency within the last 7 days** on the last-activity column.\n- **(optional)** signal-strength not in the ignore/low bucket, if that column exists.\n\nState the filter in plain language, get a yes, then `create_worksheet` on that slice. Title\nit like `Escalation Radar — <Company> — <date>`. Omit `columns` so all source columns carry\nover (keeps enrichment unblocked). After it returns, `read_table` (a couple rows) or a quick\ncount to confirm rows actually landed before enriching — worksheet hydration is async.\n\nIf the slice is huge (thousands), that's fine for the worksheet, but tell the user the\nenrichment cost scales with rows and offer to tighten (e.g. signal-strength = high/very high\nonly) before running.\n\n### Step 5 — Enrich: escalation vectors + a composite score (ONE call)\n\nCost scales with rows, not columns, so batch **all** of these into a single\n`enrich_worksheet` call. Each row's judgment is made against the full conversation\ntranscript. Create:\n\n1. **Escalation vector** — `enum`, `multi: true`. Values tuned to what Step 2 surfaced, but\n   always include the four base vectors plus a catch-all:\n   `[\"legal_threat\", \"social_media_threat\", \"executive_escalation\", \"regulatory_complaint\",\n   \"<company-specific vector(s) from web search>\", \"none\"]`.\n   Instruction: classify which escalation vector(s) this conversation shows real evidence\n   of — an explicit or strongly implied threat to (a) take legal action / involve a lawyer,\n   (b) go public / post on social / contact press, (c) escalate to an executive, named\n   leader, or \"your CEO\", (d) file a regulatory/agency complaint (e.g. CFPB, FTC, state AG\n   for a fintech). Return `none` when there's no real escalation signal — do not inflate\n   ordinary frustration into a threat.\n   **Critical — judge the customer's state, not the company's outbound messaging.** Many\n   tickets contain the *company's own* automated notices (compliance/dunning/closure emails,\n   \"your account is at risk\", \"we require documentation by X\"). A company telling a customer\n   their account is at risk is NOT itself an escalation — the escalation is the *customer's*\n   reaction to it. A vector requires evidence in the customer's own words/behavior. If the\n   transcript is only the company's outbound notice with no customer distress yet, that's a\n   lower-risk watch item, not a live escalation — lean toward `none` or a low score.\n\n2. **Escalation score** — `integer` (1–10). Instruction: rate how likely this conversation\n   is to become a real escalation if left alone, weighing: explicitness and credibility of\n   any threat (an actual \"I'm contacting my lawyer\" >> generic anger); finality of tone\n   (giving up / \"done with you\" / deadline given); unresolved duration and repeated contact;\n   and stakes named in the ticket (contractual risk, money frozen, security/data exposure,\n   business-blocking). 1 = routine, 10 = imminent and severe. Score on *escalation\n   probability × blast radius*, NOT emotional volume — a calm, specific legal threat\n   outranks an angry all-caps rant about a minor issue.\n\n3. **Escalation rationale** — `string`. One sentence: why this score, naming the specific\n   trigger. This is what makes the Slack post credible and skimmable.\n\n4. **Money-quote** — `string`. The single most telling verbatim line (≤25 words) spoken by\n   the **customer** (never the agent, and never the company's automated/system text) that\n   captures the risk — ideally a threat, ultimatum, or stark statement of harm. Verbatim, no\n   paraphrasing. Return an empty string if the customer said nothing notable (e.g. the ticket\n   is only an outbound company notice). Used directly in the Slack post, so a wrong\n   attribution here is highly visible.\n\nThen `get_enrich_status` in a loop until `done: true` (it blocks; keep calling — don't hand\nback to the user). Capture the returned column **ids** (not labels) for the next step.\n\n### Step 6 — Rank and pull the top examples\n\n`aggregate_table` / `read_table` over the worksheet, ordered by escalation score descending,\nfiltered to vector ≠ `none`. Take the **top 10** (fewer if fewer qualify — never pad). For\nthose rows, pull the id, vector(s), score, rationale, money-quote, contact reason, status,\nand recency. Then `read_conversations` on the finalist ids (≤10 per call) to (a) verify each\nmoney-quote is the customer's verbatim words and correctly attributed, and (b) capture each\nticket's **conversation link** (`ticketDoc.link`) for the post — every featured item should\ndeep-link to the actual conversation.\n\nSanity-check the ranking by eye: if the top item is obviously mis-scored — e.g. it's just the\ncompany's own compliance email with no customer reaction — drop it or note it rather than\nlaundering it into the post.\n\n### Step 7 — Format the Slack post, show it in chat, then test in DM (CHECKPOINT 2)\n\nCompose a Slack-ready post and **show it in the chat first** — do not post anything yet.\nBorrow the structure of the `support-shoutout-builder` skill (numbered items, one blockquote\nquote per item, a per-item link, a warm one-line header and closer), inverted for risk rather\nthan praise. Format (Slack mrkdwn, tuned for skimming on mobile):\n\n```\n:rotating_light: *Escalation Radar — <Company>* — <N> conversations brewing toward escalation\n_Unresolved tickets, last 7 days · <M> substantive conversations scanned · ranked by escalation risk_\n\n<one line on what's currently combustible from the web search — the dominant vector, if notable>\n\n*1. <contact reason>* — <vector emoji + label> · <X>/10 · _<status>_\n<one-sentence rationale naming the specific trigger>\n> \"<verbatim customer money-quote>\"\n<https://<conversation link>|Open case <case number> →>\n\n*2. …*\n\n_<short closing line>. Generated with Rippit._\n```\n\nNotes on format:\n- Highest score first; lead with the single most urgent item implicitly via ordering.\n- Each item deep-links to its real conversation (the `ticketDoc.link` captured in Step 6) —\n  never invent a link.\n- A worksheet link is optional; offer it but don't force it (users often want a clean\n  conversation-only post). If included, put a single scoped-worksheet link at the very end.\n  To make one, `create_worksheet` from the enriched worksheet filtered to just the featured\n  ticket ids, and link its `url`.\n- Use a small, consistent set of vector emoji (e.g. :balance_scale: legal, :ice_cube: frozen\n  funds, :arrow_up: exec, :rotating_light: fraud/severe) so the post is scannable.\n\nThen ask the user, in chat: any refinements (threshold, count, drop a vector, reword)? And —\nfollowing the shoutout skill's guardrail — **offer to send the draft to the user's own Slack\nDM first** so they can see exactly how it renders before anyone else does. Their own user ID\nis usually available from the Slack tools' context; send there with `slack_send_message`. Note\nthat DMs can't be edited via API, so each revision posts a new message — tell the user that\nrather than appearing to overwrite.\n\nOnly after the user is happy AND explicitly names a destination channel do you post to it.\nPosting to a shared channel is a send action requiring explicit per-action approval; surface\nthe consequences first (who gets @-mentioned, that it names real customers, the audience\nsize). Default to a **draft** (`slack_send_message_draft`) unless they say send live. For an\nescalation digest, @-mention a triage owner or the channel — never the agents on the tickets.\n\n### Step 8 — Offer the recurring automation\n\nOnce the user is happy with a run, offer to set it up as a **recurring Cowork task** so the\ndigest posts itself on a schedule (e.g. every weekday 8am). Key point: a recurring run can't\ndo the interactive checkpoints, so **lock in the parameters from this run** as the task\nconfig — the resolved-status set, the channel, the score threshold, the example count, and\nthe company. Write the recurring task instruction to reference those fixed values explicitly\nso it runs unattended without re-asking. Confirm the schedule and channel with the user\nbefore creating it.\n\n---\n\n## Output discipline\n\n- This is a findings deliverable — when you summarize the run in chat (beyond the Slack\n  post itself), follow the Rippit report format from `get_report_guide`: lead with the\n  headline, ground claims in verbatim quotes, no walls of prose.\n- Never fabricate a quote, a score, or a web-search finding. If a step turns up little,\n  say so plainly — a forced \"everything's on fire\" digest destroys trust the first time a\n  reader clicks through and finds a routine ticket.\n- Respect the action boundaries: building worksheets and enriching is free to do; **posting\n  to Slack and creating a recurring task both require explicit user approval** at the moment\n  of doing them.\n"
}