Rippit

View saved version →

---
name: rippit-aeo-seo-optimization
description: >-
  Build an SEO- and AEO-optimized content program grounded in a company's own
  conversation data (support chats, sales calls, etc.) via the Rippit MCP.
  Adopts the framing "I am a marketing leader looking to optimize our SEO and
  AEO," asks which topics/keywords to win, discovers which Rippit sources best
  support that angle, mines them liberally with worksheets + enrichment for real
  customer and employee language, scans the user's own company website for
  coverage and gaps, and produces a content strategy plus multiple drafted
  pieces (pillar + cluster) written into whatever docs connector the user has
  (Google Drive, Notion, etc.). Use whenever the user wants SEO/AEO/GEO content,
  a content strategy, blog/article/landing-page copy, a content cluster or pillar
  page, or marketing content informed by what customers actually say — even if
  they don't name SEO. Trigger on "optimize our SEO," "content strategy," "rank
  for," "write an article about," "AEO," or "get cited by AI." Runs as a
  multi-sub-agent pipeline.
---

# SEO / AEO Content Engine

Adopt this framing for the whole run: **"I am a marketing leader looking to
optimize our SEO and AEO."** Every decision serves that goal — turning the
company's real conversation data and existing web presence into content that
ranks in search (SEO) and gets surfaced/cited by answer engines like ChatGPT,
Perplexity, Google AI Overviews, and Claude (AEO/GEO).

The output is not one article. It is a **content strategy plus multiple drafted
pieces** organized as a pillar page with supporting cluster articles, all
grounded in evidence pulled from the company's own data.

This skill orchestrates several sub-agents. The main thread is the orchestrator:
it scopes the work, launches sub-agents, hands each the artifacts from the
prior phase, and assembles the result. Be generous with sub-agents and with
Rippit worksheets/enrichments — thoroughness beats frugality here. If a phase is
large (e.g. many topics or many data sources), split it across parallel
sub-agents.

## Phase 0 — Scope with the user (orchestrator, inline)

Before any research, confirm direction. Ask the user, in one message:

1. **Areas of interest** — "Are there particular topics, keywords, products, or
   questions you want to optimize your SEO and AEO around?" Offer a couple of
   concrete example angles so it's easy to answer, but let them steer. If they
   have none, propose candidates after Phase 1 discovery and confirm before
   drafting.
2. **Company website** — infer the likely domain from the user's email address
   (e.g. `jane@acme.com` → `acme.com`) and confirm it, or ask. This is the site
   scanned in Phase 3. Keep this generic: it is always *the user's own company*,
   never a hard-coded site.

Do not gate the whole run on a long questionnaire — get topic + domain, then move.

## Phase 1 — Strategy & outline (sub-agent: "strategist")

Give this sub-agent the user's topics and domain. It produces the **strategy
skeleton** that every later phase fills in, using the methodology in "SEO/AEO
methodology" below (search intent, pillar/cluster architecture, and the AEO
specifics that make content citable by answer engines).

Deliverable from this phase: a strategy doc containing, for each target topic:
the primary keyword + intent, the pillar page concept, 3–8 cluster article
concepts, the specific questions each piece must answer, and the target keywords
per piece. Leave clearly marked placeholders for evidence (customer quotes,
stats, pain points) so Phase 2 knows exactly what to fill.

## Phase 2 — Mine the company's data via Rippit (sub-agent(s): "researcher")

This is where the content earns its authority. The job: find the real language,
pain points, questions, objections, and wins in the company's own conversations —
from **both customers and employees** — and attach that evidence to the outline.

Do not assume which table to use. **Discover generic

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: rippit-chatbot-analysis
description: >-
  Analyze support conversations to find where an AI chatbot underperforms and human
  agents excel, turn those gaps into a prioritized knowledge-base build list, and (when a
  help center is connected) reconcile the gaps against existing documentation. Works with
  any helpdesk, any chatbot, and any help center. Use when the user asks to: analyze
  chatbot / bot gaps, compare bot vs agent (human) performance, run a deflection analysis,
  understand why the bot escalates or hands off, decide what the bot should be able to
  handle, find knowledge-base or documentation gaps, or improve / train the chatbot.
---

# Bot deflection gap analysis

Find where the chatbot fails but humans succeed, and turn that into concrete actions:
new/updated help articles, and (if a help center is connected) a coverage reconciliation
that separates "content doesn't exist" from "content exists but the bot can't find it."

This skill is intentionally **generic**. Customers run different helpdesks (Zendesk,
Intercom, Salesforce, Gladly, Kustomer, Front, …), different chatbots (Fin, Zendesk bot,
Ada, a custom LLM agent, …), and different help centers (Intercom Articles, Zendesk Guide,
a public site, or none). **Never assume** how any of these are wired. Confirm the three
things below before doing analysis.

## Analysis engine

Use the Rippit MCP tools as the analysis engine: `list_data_sources`, `describe_table`,
`describe_column`, `read_table`, `aggregate_table`, `pivot_table`, `create_worksheet`,
`enrich_worksheet` + `get_enrich_status`, `find_quotes`, and `get_report_guide`. The
worksheet-enrich path is the core: it reads each full conversation transcript and adds the
per-row judgments this analysis needs (topic, resolution, satisfaction, escalation driver).

Cost of enrichment scales with **rows, not columns** — every column in one `enrich_worksheet`
call is filled in a single LLM pass per row. So batch all needed columns into ONE call.

---

## MANDATORY: confirm these three things first

Do not skip. Use the `AskUserQuestion` tool (one question per item is fine). These are the
only parts that vary by customer, and getting them wrong invalidates the whole analysis.

### 1. The data source
- Call `list_data_sources` and look for the table of support conversations/tickets. There
  are often several (per-helpdesk tables, prior worksheets, raw tables). **Do not guess.**
- Present the candidate table(s) and ask the user to confirm which one holds the chatbot
  conversations to analyze. If multiple channels exist, confirm whether to filter to one
  source (e.g. only `intercom`) or analyze all.

### 2. How to distinguish bot-handled vs bot-escalated-to-human
This is customer- and tool-specific. `describe_table` / `describe_column` first, then ask
the user to confirm the exact rule. Common signals:
- **Tags** (e.g. `fin handled`, `fin escalated`, `bot resolved`, `handoff`, `agent bot`).
- **A team/assignee field** (bot team vs a human team), or presence of any human agent in
  an `agents`/participants column.
- **An escalation column** or status.
- **Handled by bot only** = the bot engaged and the conversation never reached a human.
- **Escalated** = the bot handed off to a human.

**Verify the rule empirically before trusting it.** A frequent trap: the "bot handled" tag
is a *superset* that also covers escalated conversations (i.e. escalated ⊂ handled). Check
overlap with an `aggregate_table` count using `CONTAINS_ALL` on the two tags. If they
overlap, define **bot-only = handled AND NOT escalated**, and **handoff = escalated**.
Report the two population sizes back to the user and confirm they look right.

### 3. Whether a help center is connected (for doc reconciliation)
- Ask the user whether their help center / knowledge base is connected as a tool (e.g. an
  Intercom, Zendesk Guide, or Help Scout connector with article-listing tools).
- If **yes**: you will run the reconciliation step (compare gaps to 

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: rippit-double-click
description: Go progressively DEEPER on a specific customer question with the Rippit MCP by repeatedly narrowing into a SUBSET of the SAME tickets. Enrich a worksheet, filter to the interesting subset, build a child worksheet over just those rows, and enrich it more richly; repeat. The population only NARROWS each step (vs. rippit-iterative-learning, which moves to different tickets). Use to drill into one already-identified segment. Only use when explicitly invoked (e.g. via its slash command); do not auto-trigger from topic detection.
---

# Rippit Double-Click (drill into a subset)

A reusable pattern for drilling into a known segment. Start broad, identify the interesting subset, then create a child worksheet over just that subset and enrich it more richly. Each step is a strict subset of the prior step. Stop when the segment is understood at the granularity the user needs.

## When this fits vs. the sibling skills

- **Double-click (this skill):** sequential; each step is a SUBSET of the prior step's tickets, enriched deeper. The question targets a specific segment.
- **Iterative:** sequential; each step moves to a DIFFERENT population based on learning. Open-ended.
- **Distributed:** parallel branches over different populations.
- **Second opinion:** same population, competing analyses, debate.

Test: does the next step narrow INTO the current rows (double-click) or move to other rows (iterative)?

## The filter route (this skill's chosen implementation)

There are two valid ways to double-click; **this skill uses the child-worksheet route**:

> Enrich the parent worksheet → filter to the interesting subset → `create_worksheet` over that subset → enrich the child more deeply → repeat.

The alternative (running additional enrichments in-place on filtered rows of the SAME worksheet) is intentionally NOT the default here. Use the child-worksheet route so each depth level persists as its own worksheet the user can open, aggregate, and report on independently.

## Workflow overview

1. **Setup (main turn).** Discover source, confirm columns/labels, name the segment to drill into.
2. **Drill loop.** Each level: enrich → find the subset → child worksheet on that subset → deeper enrich. Run sequentially in the main turn (each level depends on the last).
3. **Deliver** the deepest finding with the trail of narrowing.

---

## Step 1 — Setup

1. `list_data_sources` → source table.
2. `describe_table` → date column, conversation id column (`external_id`), enum columns.
3. `aggregate_table` on relevant enums to read actual labels.
4. State the **starting population** and the **segment you intend to drill into** to the user.

---

## Step 2 — The drill loop

Keep a running note of the row count at each level so the funnel is visible (e.g. 4,000 → 600 → 90).

**Level 0 (parent):**
1. `create_worksheet` over the starting population.
2. `read_table` to confirm rows → `enrich_worksheet` with broad classifying columns (enough to identify which subset is worth drilling into). Batch into one call; catch-all on every enum.
3. `get_enrich_status` until done → `aggregate_table` to find the subset that warrants depth.

**Each subsequent level (N+1):**
1. **Define the filter** that isolates the interesting subset of level N's rows (e.g. `where primary_driver = "billing_dispute" AND severity >= 4`).
2. `create_worksheet` from level N's worksheet (or the source with the cumulative filter) restricted to that subset. This child is a strict subset.
3. Confirm rows, then `enrich_worksheet` with **deeper, more specific columns** than the parent — finer subcategories, exact failure mechanics, verbatim quotes, sequence-of-events. The whole point is that you can afford richer per-row judgment because the population is smaller and more homogeneous.
4. `get_enrich_status` until done → analyze.
5. Decide: drill again into a sub-subset, or stop.

**Exit criteria:**
- The segment is explained at the granularity the user asked for.

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: rippit-escalation-finder
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.
---

# Escalation Radar

Surface support conversations that are quietly turning into escalations — legal exposure,
a social-media flare-up, or a complaint headed for an executive's inbox — before they do.
The output is a tight, ranked Slack post of the most pressing examples, plus an optional
recurring automation.

The core idea: **the data already knows which tickets are unresolved and noisy; what it
doesn't know is which ones carry real escalation risk for *this specific company right
now*.** A web search grounds the run in what's currently combustible for the customer
(recent outages, regulatory heat, public complaints), and a fresh enrichment pass scores
each conversation against those vectors. Don't trust pre-existing "churn risk" style
columns to do this — they're inconsistent across customers and weren't built for this
question. Build the judgment fresh.

## When NOT to over-engineer

If the user just wants a count or a simple distribution ("how many unresolved tickets this
week"), that's a plain `aggregate_table` call, not this skill. This skill earns its weight
when the user wants *which specific conversations are dangerous and why* — a ranked,
human-readable shortlist with evidence.

---

## Workflow

Run these in order. Confirm with the user at the two marked checkpoints — don't barrel
through them, because a wrong status filter or a wrong company guess silently corrupts
everything downstream.

### Step 1 — Identify the customer (the company whose tickets these are)

Call `list_data_sources`. In the common case there is one obvious support-cases table; use
it. If several tables exist, pick the one that holds support conversations (look for
columns like contact reason, status, sentiment, conversation summary) and, if it's
genuinely ambiguous, ask the user which table.

Determine **which company this data belongs to** — i.e. the Rippit customer. This is NOT a
per-row "requester's employer"; every row is the customer's own support traffic. Infer the
company from the table name and from `describe_table` content — product-area values, case
origins, and competitor mentions usually name the company outright (e.g. product areas like
"[Fintech Company] Card", "[Fintech Company] Dashboard" → the company is that Fintech
Company). If you cannot infer it confidently,
ask the user: "Which company's support data is this?"

### Step 2 — Ground the run in the company's current risk surface (web search)

Web-search the company for **recent, specific** escalation fuel — not a generic industry
lecture. Aim 4–8 searches at things that would make a support ticket more likely to
escalate *this month*:

- recent outages, incidents, or degraded-service reports
- regulatory actions, investigations, lawsuits, or compliance scrutiny
- public complaints, viral threads, BBB/Trustpilot/Reddit/X flare-ups, press
- anything sector-specific that raises the stakes of a mishandled ticket (for a fintech:
  frozen funds, account closures, fraud liability, KYC lockouts; for a marketplace:
  refunds, safety; etc.)

Synthesize this

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: rippit-qa-program-revamp
description: >-
  Build and run a repeatable "ticket-insights" QA program that measures something
  meaningful on EVERY support ticket — contact reason, root cause, avoidability,
  resolution quality, product signal, and churn/at-risk — instead of just scoring
  agents. Use this whenever the user wants to redesign, rebuild, or stand up a QA
  or support-analytics program; shift QA from agent scorecards to ticket/insight
  focus; systematically tag, classify, or score every ticket; find contact
  drivers, avoidable volume, product feedback, or at-risk accounts from support
  conversations; or set up a recurring support-insights readout. Trigger even if
  the user doesn't say "QA" — e.g. "what should we measure on every ticket",
  "turn our support tickets into insights", "find what's driving contacts",
  "which tickets put revenue at risk". Works with ANY helpdesk or conversation
  data source and ANY set of connectors; do not assume a specific integration.
---

# Ticket-Insights Program Builder

Help the user design and run a QA/support-analytics program organized around the
**ticket**, not the agent. The old model asks "did the agent follow the rubric?"
This model asks, on every ticket: *why did this contact exist, was it preventable,
did the customer actually get helped, and what does it tell the rest of the
business?* Agent quality falls out as a lightweight byproduct.

You are acting as a **thought partner**, not an order-taker. Push back on vague or
over-broad goals, help the user sharpen them, and make sure every measure ladders
up to a decision someone can own. A measure nobody will act on is noise — cut it.

This skill is **integration-agnostic**. It assumes nothing about which helpdesk,
CRM, or connectors exist. You will discover what's available at runtime and adapt.

## The core idea: measure a causal chain, not a topic list

A strong per-ticket schema follows a chain, because one enrichment pass then feeds
many different questions:

**contact reason → root cause → avoidable? → resolution outcome → product signal → customer risk**

- Volume-reduction questions read *reason, root cause, avoidable*.
- Resolution-quality questions read *outcome, effort*.
- Product questions read *product signal, product area*.
- Revenue-risk questions read *sentiment, churn/escalation risk*.

Design around this chain and you avoid the classic failure mode of tagging surface
topics that look tidy but drive no action.

## Workflow

Follow these steps in order. Use a task list to track them. Don't skip the
elicitation step (Step 2) — getting the goals right is the whole game.

### Step 1 — Discover the data and connectors (before asking anything heavy)

Ground the conversation in what actually exists so your questions are concrete.

1. List the available source-of-truth data tables / conversation sources (e.g. a
   Rippit-style `list_data_sources`, a data-warehouse connector, an uploaded
   export). Inspect the schema of the most relevant ticket/conversation table to
   see what's already captured (status, timestamps, channel, subject, agent) vs.
   what must be derived from transcripts.
2. Take stock of **other connectors available in this Claude session** — search
   the connector registry and note anything that could supply business context:
   CRM/Salesforce/HubSpot (account value, ARR, tier), help center (docs to
   reconcile against), Slack/email (escalations), product analytics. You will use
   these later to enrich and to size at-risk tickets.
3. If no ticket data is reachable at all, say so plainly and offer paths: connect a
   helpdesk/warehouse connector, or upload an export. Don't fabricate data.

Report back briefly: what data you found, roughly how much (row count / date
range), and which connectors could add business context.

### Step 2 — Elicit goals and focus areas (REQUIRED, use a structured question)

Do not design the program from assumptions. Use the environment's structured
questio

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: rippit-support-shoutouts
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.
---

# Support Shout-out Builder

Turn raw support conversations into a recognition post that celebrates agents
who went above and beyond — backed by real quotes — and deliver it safely to a
chat channel only after the user has reviewed it.

This skill is **support-specific** but **tool-agnostic**. It assumes you have
some way to (a) read/analyze support conversations and (b) post a message to a
chat tool. Use whatever data-analysis and messaging tools are connected in the
current environment. Discover them rather than assuming specific products.

## The core promise

The user does not want three *random* conversations that technically qualify.
They want the *best* ones: cases where the agent's extra effort is concrete and
specific, and the customer's gratitude is vivid and personal. Ranking quality is
the whole point — do not shortcut it.

And: **nothing gets posted to a shared channel without explicit confirmation.**
The default safe path is test-in-DM first.

---

## Workflow overview

1. Clarify scope (count, time window, channel, recurring?)
2. Locate the support-conversation data
3. Build the candidate worksheet — **without filtering on possibly-empty enriched columns**
4. Rank for genuine "above and beyond" + customer appreciation
5. Verify quotes against the real transcripts
6. Draft the recognition message
7. **Send to the user's own DM first to test** (confirm this is what they want)
8. Revise messaging as needed
9. Ask which channel to share in — **never post without confirmation**
10. Optionally schedule it on a recurring basis

Work through these in order. Steps 7–9 are guardrails, not suggestions.

---

## Step 1 — Clarify scope

Before doing anything, confirm a few things (ask only what isn't already clear
from the request):

- **How many wins** to feature (default: 3). It is fine to return fewer if not
  enough conversations clear the quality bar — say so rather than padding.
- **Time window** (e.g., last 30 days, last quarter, all-time). Recency matters
  for recurring digests.
- **Source filter**, if any (a particular team, queue, product line, channel).
- **Recurring?** Ask whether this is a one-off or something they want on a
  cadence (e.g., weekly/monthly). This changes the time window and how Step 10
  is handled.

Keep this light — one short round of questions, then proceed.

---

## Step 2 — Locate the support-conversation data

Discover what's available rather than assuming. Look for a data source that
holds support conversations/tickets. Useful signals that a table is the right
one: columns for conversation text or summaries, ticket status, customer
sentiment, CSAT, resolution, and any pre-computed/AI-enriched fields (sentiment,
"resolved?", quotes, themes).

If multiple sources exist, prefer the one that already has enrichment columns —
it saves work — but verify those columns are actually populated (see Step 3).

Inspect the schema before querying so you know the real column identifiers and
their distinct values. Don't guess column names.

---

## Step 3 — Build the candidate worksheet (critica

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: rippit-tool-bakeoff
description: >-
  Run a controlled head-to-head ("bake-off") between two or more analysis tools
  (e.g. the Rippit MCP vs. a Snowflake/SQL MCP, or any data/connector MCP) on the
  SAME deep-dive question, using isolated Cowork sub-agents, then present each tool's
  output and the process behind it side by side in the chat so the user can judge for
  themselves. Use when the user
  wants to compare tools/MCPs, benchmark connectors, run a tool bake-off, see how
  different tools answer the same question, or A/B two analysis engines on real data.
  Triggers: "compare X MCP and Y MCP", "bake-off", "which tool is better at", "run
  the same analysis with both tools", "head-to-head", "benchmark these connectors".
---

# Tool Bake-off

Run the same analytical question through two or more tools in parallel, each handled
by an **independent, isolated Cowork sub-agent** that cannot see the others' work,
then present each tool's results — output and process — side by side **directly in the
chat**, so the user can see exactly how the tools differ and decide for themselves
which they trust. This produces a defensible, apples-to-apples view of "how does each
tool answer this question?" — with the *difference* between the outputs unmistakable.

## Inputs (collect these first)

The user should provide two things when they invoke the skill. If either is missing,
ASK for it (use the AskUserQuestion tool, one concise question per missing item)
before doing anything else:

1. **Tools to compare** — the **Rippit MCP is ALWAYS one side of the comparison**;
   never ask whether to include it, just include it. Ask only for the OTHER tool(s)
   to compare it against (e.g. Snowflake/SQL, another connector, or a variant such
   as "Snowflake raw + Cortex" vs "Snowflake raw, no Cortex"). Confirm the exact MCP
   server identifiers so each sub-agent can be locked to its tool.
2. **The question** — the deep-dive the user wants answered (e.g. "why are customers
   reaching out over the past 3 months?").

Results are presented in the chat — do NOT write to or ask for any external doc
(Notion, Google Docs, Slack, a file). The whole comparison surfaces inline.

Do not start work until both are known.

## Step 1 — Confirm scope

Restate the tools and the question in one line so the user can correct you. Identify
each tool's MCP server prefix (e.g. `mcp__<server-id>__*`) so sub-agents can be made
**tool-pure**.

## Step 2 — Beef up the question (then proceed)

A thin question produces thin, hard-to-differentiate answers. Deepen the user's
question into a rigorous brief by layering in the dimensions below **that are
relevant to their question** — apply them tool-agnostically (the goal is a better
analysis, not a rigged one):

- **Coverage + reproducibility** — aim to analyze all of the relevant records; but if
  the question spans so many records that full coverage is impractical, the tool may
  sample, and should choose a sensible sample (e.g. representative, not just whatever's
  newest or easiest). Either way it must be upfront about exactly what it covered (all
  records, or a sample of what size and how chosen) so the user can weigh it. Results
  should be reproducible run-to-run.
- **Structured taxonomy / segmentation** — if the question is "why/what kind",
  require a multi-level, mutually-exclusive taxonomy with dynamic depth and the
  volume/% per bucket; where useful, break results down by segment (e.g. tier, ARR
  band, tenure, region, product area).
- **Severity dimensions** — urgency, business impact, and sentiment/CSAT impact per
  finding, not just counts.
- **Evidence with receipts** — for each theme, representative verbatim quotes with
  links/IDs to source records, plus the single most severe example.
- **Quotes for color** — weave representative customer quotes into the analysis to
  add color and human texture to the quantitative story, not just as an appendix.
- **Root cause vs. symptom** — classify the underlyin

Preview of the first 4,000 characters. Read full instructions →