Update to Rippit

{
  "description": "Find the best \"above and beyond\" customer-support conversations — where an agent went the extra mile and the customer was visibly grateful — and turn them into a polished recognition message for Slack (or another chat channel). Use this whenever someone wants to celebrate, recognize, or shout out support agents; surface \"great support moments,\" \"wins,\" \"kudos,\" or \"appreciation\" stories from support tickets/conversations; build a team recognition post; or schedule a recurring support-wins digest. Trigger it even if the person only says something like \"find me some great support interactions to highlight\" or \"put together a kudos post for the support team\" — this skill defines the full find → rank → draft → test-in-DM → confirm-channel → (optionally) schedule workflow, and it never posts to a shared channel without explicit confirmation.",
  "included_files": [],
  "name": "rippit-support-shoutouts",
  "skill_md_contents": "---\nname: rippit-support-shoutouts\ndescription: >-\n  Find the best \"above and beyond\" customer-support conversations — where an\n  agent went the extra mile and the customer was visibly grateful — and turn\n  them into a polished recognition message for Slack (or another chat channel).\n  Use this whenever someone wants to celebrate, recognize, or shout out support\n  agents; surface \"great support moments,\" \"wins,\" \"kudos,\" or \"appreciation\"\n  stories from support tickets/conversations; build a team recognition post; or\n  schedule a recurring support-wins digest. Trigger it even if the person only\n  says something like \"find me some great support interactions to highlight\" or\n  \"put together a kudos post for the support team\" — this skill defines the full\n  find → rank → draft → test-in-DM → confirm-channel → (optionally) schedule\n  workflow, and it never posts to a shared channel without explicit confirmation.\n---\n\n# Support Shout-out Builder\n\nTurn raw support conversations into a recognition post that celebrates agents\nwho went above and beyond — backed by real quotes — and deliver it safely to a\nchat channel only after the user has reviewed it.\n\nThis skill is **support-specific** but **tool-agnostic**. It assumes you have\nsome way to (a) read/analyze support conversations and (b) post a message to a\nchat tool. Use whatever data-analysis and messaging tools are connected in the\ncurrent environment. Discover them rather than assuming specific products.\n\n## The core promise\n\nThe user does not want three *random* conversations that technically qualify.\nThey want the *best* ones: cases where the agent's extra effort is concrete and\nspecific, and the customer's gratitude is vivid and personal. Ranking quality is\nthe whole point — do not shortcut it.\n\nAnd: **nothing gets posted to a shared channel without explicit confirmation.**\nThe default safe path is test-in-DM first.\n\n---\n\n## Workflow overview\n\n1. Clarify scope (count, time window, channel, recurring?)\n2. Locate the support-conversation data\n3. Build the candidate worksheet — **without filtering on possibly-empty enriched columns**\n4. Rank for genuine \"above and beyond\" + customer appreciation\n5. Verify quotes against the real transcripts\n6. Draft the recognition message\n7. **Send to the user's own DM first to test** (confirm this is what they want)\n8. Revise messaging as needed\n9. Ask which channel to share in — **never post without confirmation**\n10. Optionally schedule it on a recurring basis\n\nWork through these in order. Steps 7–9 are guardrails, not suggestions.\n\n---\n\n## Step 1 — Clarify scope\n\nBefore doing anything, confirm a few things (ask only what isn't already clear\nfrom the request):\n\n- **How many wins** to feature (default: 3). It is fine to return fewer if not\n  enough conversations clear the quality bar — say so rather than padding.\n- **Time window** (e.g., last 30 days, last quarter, all-time). Recency matters\n  for recurring digests.\n- **Source filter**, if any (a particular team, queue, product line, channel).\n- **Recurring?** Ask whether this is a one-off or something they want on a\n  cadence (e.g., weekly/monthly). This changes the time window and how Step 10\n  is handled.\n\nKeep this light — one short round of questions, then proceed.\n\n---\n\n## Step 2 — Locate the support-conversation data\n\nDiscover what's available rather than assuming. Look for a data source that\nholds support conversations/tickets. Useful signals that a table is the right\none: columns for conversation text or summaries, ticket status, customer\nsentiment, CSAT, resolution, and any pre-computed/AI-enriched fields (sentiment,\n\"resolved?\", quotes, themes).\n\nIf multiple sources exist, prefer the one that already has enrichment columns —\nit saves work — but verify those columns are actually populated (see Step 3).\n\nInspect the schema before querying so you know the real column identifiers and\ntheir distinct values. Don't guess column names.\n\n---\n\n## Step 3 — Build the candidate worksheet (critical guardrail)\n\nCreate a working slice (worksheet/filtered table) of plausible candidates.\n\n**Guardrail — do not filter on enriched columns that may be unpopulated for\nrecent tickets.** Enrichment (sentiment, \"issue resolved,\" extracted quotes,\netc.) is often computed on a lag. If you filter the initial population on an\nenriched column, recently-closed conversations whose enrichment hasn't run yet\nwill be silently excluded — exactly the fresh wins a recurring digest wants.\n\nSo:\n\n- For the **initial candidate population**, filter only on **reliably-populated,\n  source-of-truth fields**: source/channel, date range, ticket status (e.g.\n  closed), team/queue. These are written at ingest and are safe.\n- **Before** you rely on any enriched column as a filter, check that it's\n  actually populated for the time window in question. A quick way: aggregate the\n  count of non-empty values for that column within the date range, or sample a\n  few recent rows. If a meaningful share of recent rows is empty/blank/unknown,\n  **do not use that column as a filter** — instead, pull the broader population\n  and let your own ranking pass (Step 4) do the work on every row.\n- If enriched columns *are* well-populated for the window, you may use them to\n  narrow (e.g., positive sentiment + resolved) — but treat this as an\n  optimization, not a requirement.\n\nThe safe default when in doubt: filter only on source + date + status, then\nenrich/score every row yourself in Step 4.\n\n---\n\n## Step 4 — Rank for genuine \"above and beyond\" + appreciation\n\nThis is where quality is won. Judge against the **full conversation transcript**,\nnot a one-line summary — the extra-mile behavior and the gratitude live in the\nback-and-forth.\n\nScore each candidate on two independent dimensions. If the environment supports\nadding AI/enrichment columns to the worksheet, add them; otherwise read the\ntranscripts and score directly. Cost scales with rows, so add all the columns\nyou need in a single pass.\n\n**Dimension A — \"Above and Beyond\" (0–10).** How far past ordinary competent\nservice did the agent go? Be a harsh grader.\n- Score **8–10** only for unmistakable extra-mile behavior: proactively\n  investigating beyond what was asked, building or finding a custom\n  workaround/fix, doing manual work on the customer's behalf, personally\n  escalating and following through, jumping on an unscheduled call, anticipating\n  and preventing a *future* problem, working outside hours, unusual ownership.\n- Score **0–3** for routine \"here's the answer / here's the doc / fixed it\" —\n  even when friendly and resolved. Most resolved-positive tickets are routine.\n\n**Dimension B — Customer Appreciation Intensity (0–10).** How strongly and\nexplicitly did the *customer* express gratitude? Be a harsh grader.\n- Score **8–10** for effusive, specific praise — naming the agent, \"you went\n  above and beyond,\" \"best support I've had,\" \"you saved us,\" exclamation-heavy\n  thanks, praising the *person* not just the outcome.\n- Score **4–6** for a sincere \"thank you so much, really appreciate it.\"\n- Score **0–3** for a perfunctory \"thanks\" or none at all.\n\nAlso extract, per row, **one verbatim agent quote** showing the extra mile and\n**one verbatim customer quote** showing the praise (return a clear \"NONE\"\nsentinel when absent, so you can exclude those rows).\n\n**Selecting the winners.** Filter to rows scoring high on **both** dimensions\n(e.g., both ≥ 8) with non-empty quotes. Then read the actual quotes and pick the\nfinal set by judgment, favoring:\n- a **concrete, specific** agent action (built/recreated/cleaned up/prevented),\n  over vague \"I flagged it to the team\";\n- the **most vivid, personal** customer praise;\n- **variety of agents** for a team shout-out (spread recognition) unless the\n  user asked strictly for top-N-by-score.\n\nIf fewer than the requested number clear the bar, **return fewer** and say why.\nDo not lower the bar to hit a number.\n\n---\n\n## Step 5 — Verify quotes against the real transcripts\n\nBefore any quote goes into a message, confirm it against the source\nconversation. Pull the full records for your finalists and check that:\n- both quotes appear **verbatim** and are correctly attributed (agent vs.\n  customer);\n- the customer's name, account/company, and the agent's name are right;\n- the described \"above and beyond\" action actually happened.\n\nCatching a misattribution here is cheap; catching it after posting is not. Note\nand fix any discrepancy (e.g., wrong company pulled from an email domain).\n\nAlso capture, for each finalist, a **link to the conversation** if the data\nexposes one — useful in the post.\n\n---\n\n## Step 6 — Draft the recognition message\n\nWrite a warm, scannable post. A reliable structure:\n\n```\n[eye-catching header — celebrating support wins]\n\n[one-line intro: these are cases where the team went the extra mile\n and the customer noticed]\n\n[For each win, numbered:]\n*N. [Agent] → [Customer/Account]*\n[1–2 sentences on what the agent did that was exceptional]\n> [Agent]: \"[verbatim agent quote]\"\n> [Customer]: \"[verbatim customer quote]\"\n[link to the conversation, if available]\n\n[short closing line of appreciation to the agents]\n```\n\nFormatting tips:\n- Match the target chat tool's markup (e.g., Slack uses `*bold*`, `_italic_`,\n  `>` blockquotes).\n- To **tag/mention agents** in the message, resolve each agent's *name* (from\n  the transcript) to that chat tool's *user ID* via its user-lookup capability,\n  then use the tool's mention syntax (e.g., Slack `<@USERID>`). Do not paste raw\n  names and assume they'll notify anyone. Confirm each match is unambiguous\n  (e.g., name + work email) before using it.\n- If a quote contains a placeholder or broken link from the original\n  conversation, trim it rather than reproducing it.\n\n---\n\n## Step 7 — Test in the user's own DM first\n\n**Always offer to send the draft to the user's own direct message first**, so\nthey can see exactly how it renders before anyone else does. Confirm this is\nwhat they want:\n\n> \"Want me to send this to your own DM first so you can see how it looks?\"\n\nIf yes, look up the current user's own ID and send the draft there. Note that\nmentions typically render as plain linked names in a DM (they don't notify the\ntagged people from a self-DM), which makes it a safe test.\n\nShare the resulting message link so they can open it.\n\n---\n\n## Step 8 — Revise as needed\n\nIterate on wording, ordering, which wins are included, tone, length — whatever\nthe user asks. Re-send the revised version to their DM if they want to see it\nagain. Stay in this loop until they're happy.\n\nIf the user changes their mind about content they previously cut (links,\nquotes, an extra win), accommodate it without friction.\n\n---\n\n## Step 9 — Confirm the destination channel, then post\n\n**Never post to a shared/team channel without explicit confirmation.** This is\nthe most important rule in the skill.\n\nAsk which channel they want to share it in:\n\n> \"Which channel should I post this to?\"\n\nThen:\n1. Resolve the channel name to its ID via the chat tool's channel-search.\n2. **Confirm before sending**, and surface anything irreversible or\n   easy-to-regret in that confirmation:\n   - it will notify everyone tagged (agents get pinged in a real channel,\n     unlike the DM test);\n   - it names real customers, if it does — fine internally, worth a beat before\n     it's company-wide;\n   - the audience size (e.g., a company-wide #general vs. a small team channel).\n3. Only after a clear \"yes,\" post it.\n4. Return the posted message link.\n\nIf the user names the channel and says \"send it\" in the same breath, you may\ntreat that as the confirmation — but still state the audience/mention\nconsequences in one line before sending.\n\n---\n\n## Step 10 — Optional recurring schedule\n\nIf the user wants this on a cadence:\n\n- Many chat tools support **scheduled messages**; if available, you can schedule\n  the *next* run's post. But the *content* must be regenerated each period from\n  fresh data — a scheduled message is static text, so don't schedule a stale\n  post far in advance as if it were dynamic.\n- The honest framing for true recurrence: this skill is the repeatable workflow.\n  Each period, re-run Steps 1–9 against the new time window (Step 3's guardrail\n  matters most here — recent wins are exactly the ones whose enrichment may lag).\n- If the environment has a scheduler/automation/cron capability, offer to wire\n  the workflow to it. If it doesn't, tell the user plainly that you can't create\n  a standing automation from here, and the practical path is to re-run this\n  skill on their chosen cadence (e.g., \"ping me every Monday and I'll build that\n  week's post\"). Don't imply a recurring job exists when it doesn't.\n- For a recurring **digest**, default the time window to the period since the\n  last run and lead with the freshest wins.\n\n---\n\n## Guardrails recap\n\n- Rank for *genuine* quality; harsh grading on both dimensions; return fewer than\n  requested rather than padding with weak entries.\n- Build the initial candidate set from **reliably-populated source fields only**;\n  verify any enriched column is populated for recent tickets **before** filtering\n  on it.\n- Verify every quote verbatim against the transcript and check attribution.\n- **Test in the user's DM first**; revise; then **confirm the channel**; **never\n  post to a shared channel without explicit confirmation**, and flag mention/\n  customer-name/audience consequences before sending.\n- Be honest about what \"recurring\" can and can't do in the current environment.\n"
}