Update to Rippit

{
  "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\".",
  "included_files": [],
  "name": "rippit-tool-bakeoff",
  "skill_md_contents": "---\nname: rippit-tool-bakeoff\ndescription: >-\n  Run a controlled head-to-head (\"bake-off\") between two or more analysis tools\n  (e.g. the Rippit MCP vs. a Snowflake/SQL MCP, or any data/connector MCP) on the\n  SAME deep-dive question, using isolated Cowork sub-agents, then present each tool's\n  output and the process behind it side by side in the chat so the user can judge for\n  themselves. Use when the user\n  wants to compare tools/MCPs, benchmark connectors, run a tool bake-off, see how\n  different tools answer the same question, or A/B two analysis engines on real data.\n  Triggers: \"compare X MCP and Y MCP\", \"bake-off\", \"which tool is better at\", \"run\n  the same analysis with both tools\", \"head-to-head\", \"benchmark these connectors\".\n---\n\n# Tool Bake-off\n\nRun the same analytical question through two or more tools in parallel, each handled\nby an **independent, isolated Cowork sub-agent** that cannot see the others' work,\nthen present each tool's results — output and process — side by side **directly in the\nchat**, so the user can see exactly how the tools differ and decide for themselves\nwhich they trust. This produces a defensible, apples-to-apples view of \"how does each\ntool answer this question?\" — with the *difference* between the outputs unmistakable.\n\n## Inputs (collect these first)\n\nThe user should provide two things when they invoke the skill. If either is missing,\nASK for it (use the AskUserQuestion tool, one concise question per missing item)\nbefore doing anything else:\n\n1. **Tools to compare** — the **Rippit MCP is ALWAYS one side of the comparison**;\n   never ask whether to include it, just include it. Ask only for the OTHER tool(s)\n   to compare it against (e.g. Snowflake/SQL, another connector, or a variant such\n   as \"Snowflake raw + Cortex\" vs \"Snowflake raw, no Cortex\"). Confirm the exact MCP\n   server identifiers so each sub-agent can be locked to its tool.\n2. **The question** — the deep-dive the user wants answered (e.g. \"why are customers\n   reaching out over the past 3 months?\").\n\nResults are presented in the chat — do NOT write to or ask for any external doc\n(Notion, Google Docs, Slack, a file). The whole comparison surfaces inline.\n\nDo not start work until both are known.\n\n## Step 1 — Confirm scope\n\nRestate the tools and the question in one line so the user can correct you. Identify\neach tool's MCP server prefix (e.g. `mcp__<server-id>__*`) so sub-agents can be made\n**tool-pure**.\n\n## Step 2 — Beef up the question (then proceed)\n\nA thin question produces thin, hard-to-differentiate answers. Deepen the user's\nquestion into a rigorous brief by layering in the dimensions below **that are\nrelevant to their question** — apply them tool-agnostically (the goal is a better\nanalysis, not a rigged one):\n\n- **Coverage + reproducibility** — aim to analyze all of the relevant records; but if\n  the question spans so many records that full coverage is impractical, the tool may\n  sample, and should choose a sensible sample (e.g. representative, not just whatever's\n  newest or easiest). Either way it must be upfront about exactly what it covered (all\n  records, or a sample of what size and how chosen) so the user can weigh it. Results\n  should be reproducible run-to-run.\n- **Structured taxonomy / segmentation** — if the question is \"why/what kind\",\n  require a multi-level, mutually-exclusive taxonomy with dynamic depth and the\n  volume/% per bucket; where useful, break results down by segment (e.g. tier, ARR\n  band, tenure, region, product area).\n- **Severity dimensions** — urgency, business impact, and sentiment/CSAT impact per\n  finding, not just counts.\n- **Evidence with receipts** — for each theme, representative verbatim quotes with\n  links/IDs to source records, plus the single most severe example.\n- **Quotes for color** — weave representative customer quotes into the analysis to\n  add color and human texture to the quantitative story, not just as an appendix.\n- **Root cause vs. symptom** — classify the underlying driver (product gap, doc gap,\n  policy, training, expected behavior) and what would have prevented it.\n- **Trend** — what's rising, falling, or newly emerging vs. the prior period.\n- **Closed-loop action** — a tactical, implementable set of top recommendations\n  (product / policy / agent training), and where supported, drafted artifacts\n  (tickets, help articles, coaching guidance) and tagged records.\n\nBriefly tell the user you're enriching their question — something like *\"Adding a few\nextra angles to your question so it gets answered as fully as possible\"* — then show\nthe beefed-up brief and **proceed straight to dispatching the sub-agents**. Do not ask\nfor approval or pause; presenting the brief is a heads-up, not a checkpoint. (If the\nuser objects or edits after seeing it, adjust and re-run.)\n\n## Step 3 — Dispatch one isolated sub-agent per tool (in parallel)\n\nLaunch the sub-agents in a single message so they run concurrently. Each sub-agent\ngets the **identical brief** and these hard rules in its prompt:\n\n- **Tool-pure:** it may use ONLY its assigned tool's MCP for data (give the exact\n  `mcp__<server-id>__*` prefix). It must NOT use any other data tool, and must find\n  the data within its own tool.\n- **Isolation:** it works alone and must not assume any other analysis exists.\n- **Return, don't write:** it must NOT write its report to any external doc (no Notion,\n  Google Docs, Slack, file). It composes its full report and **returns it as its final\n  message** to the orchestrator, which surfaces it in the chat.\n- **Format for the depth it found:** it chooses whatever formatting best fits the depth\n  and shape of its own answer — tables, nested taxonomy, callouts, quote blocks,\n  whatever conveys its findings most clearly. The format itself is a signal: a tool that\n  found rich, multi-axis structure should look richer than one that found a flat list.\n  Do not force a shared template; let each report's structure reflect what the tool\n  actually produced.\n- **Deferred tools:** remind it to load tool schemas via ToolSearch\n  (`select:<toolname>`) before calling them.\n- **No fabrication:** every number must come from its tool's results; it must report\n  its methodology, exact coverage (full vs. sample), and candid limitations.\n- **Time itself:** it must record a wall-clock timestamp the moment it starts work and\n  again when its report is fully written, compute the elapsed time, and include a\n  **\"Time to insight: Xm Ys\"** line near the top of its report. This must be a real\n  measured duration, not an estimate — it's the speed signal for the final comparison.\n- **Log its own process — in plain language:** it must include a **\"How this was done\"**\n  section that a non-technical reader can follow. The substance still matters — how much\n  of the data it actually looked at, whether it read full conversations or just the\n  opening message or a summary field, whether it judged each conversation individually\n  or grouped them by keywords/labels, and anything that got in the way (it couldn't\n  reach some data, had to work from a sample, etc.). But it must say this in everyday\n  words and explain *why it matters for trusting the answer*, not list the machinery.\n  Drop the jargon: no tool/function names, error codes, parameters, \"pagination,\"\n  \"tokens,\" \"enrichment,\" \"DSL,\" and the like. Translate the mechanics into plain\n  outcomes. For example, instead of *\"search_conversations paged 12× at 150/page; pages\n  exceeded the token cap so I persisted them to temp files and grepped Body: lines;\n  ERR_NETWORK_CHANGED on retries; 16% body sample, recency-weighted\"*, write something\n  like *\"I was able to pull exact totals for the whole period, but I could only read the\n  full text of about 1 in 6 conversations — the newest ones — because the connection\n  kept dropping on larger pulls. So the overall counts are solid, but the breakdown of\n  themes is a directional estimate from a recent sample, not an exact read of every\n  conversation.\"* Keep it honest and specific about coverage and limits; just make it\n  readable. This section is what lets the user judge how much to trust each report, so\n  it can't be a sanitized everything-went-great summary.\n- **Permanent artifact:** it must note whether the analysis leaves behind a durable,\n  re-openable artifact and link/identify it. For the **Rippit** sub-agent this is the\n  **worksheet (or set of worksheets)** it created — capture their IDs/URLs. For other\n  tools, note whatever persists (a saved query, a table, a notebook) or state plainly\n  that the analysis leaves no artifact beyond the report itself.\n\nEach sub-agent returns its **complete, self-formatted report** as its final message,\nwhich must include: its **time to insight (elapsed duration)**, its plain-language\n**\"How this was done\"** section (coverage, how conversations were analyzed, and any\nlimits — no jargon), the record count + date range, the full findings (taxonomy,\nseverity, root cause, trend, recommendations as the brief required), **whether it\nproduced a permanent artifact (and its ID/link)**, and any limitations it hit.\n\n## Step 4 — Present a side-by-side comparison in the chat\n\nRead every sub-agent's returned report **in full**, then build a single, structured\n**side-by-side** comparison **directly in the Cowork chat** — no external doc, and\n**no verdict**. The point is for the user to scan the two tools next to each other,\ndimension by dimension, and judge for themselves. This is the opposite of dumping two\nlong reports back to back: pull the findings into shared, parallel structures so the\ndifferences jump out.\n\nUse the section structure below (it mirrors a clean at-a-glance comparison). Label the\ntwo tools consistently throughout (e.g. \"A — [Other tool]\" and \"B — Rippit\"). Use real\nchat tables for the columnar sections.\n\n1. **Title + question callout.** A title naming the two tools, then a short callout with\n   the exact question, the date range analyzed, and one line noting both tools ran the\n   *identical* brief in isolation, with no verdict — \"compare for yourself.\"\n2. **At a glance** — a table with one row per process/meta dimension and one column per\n   tool. Include: **Time to insight**, **Records analyzed**, **Coverage** (full vs.\n   sample, stated plainly), **How reasons were classified** (read every conversation vs.\n   leaned on an existing label / opening message), **Data hygiene** (what was filtered\n   in/out to get to the analyzed set), **Permanent artifact** (Rippit's re-openable\n   worksheet vs. none — use a ✅/❌), **Self-reported reliability** (how much each tool\n   says to trust its own numbers), and **Friction hit** (what got in the way). Keep every\n   cell plain-language, not jargon.\n3. **Top [findings] side by side** — a table of the headline findings (e.g. contact\n   reasons / themes) with one column per tool showing each tool's number or bucket for\n   that row. Because tools often bucket differently, add a short callout right after\n   noting the taxonomies aren't 1:1 and *how* each organized its categories — that\n   mismatch is itself one of the most revealing differences.\n4. **Where they agreed** — a few bullets on the substantive conclusions both tools\n   reached independently (genuine agreement across isolated agents is meaningful signal).\n5. **Most severe example each surfaced** — a two-column table (or paired blocks) with the\n   single worst/most-escalated case each tool pulled, including the verbatim quote and a\n   source ID/link. The two will usually differ, which is informative.\n6. **Process, in each tool's own words** — a short verbatim excerpt from each tool's\n   plain-language \"How this was done\" section, attributed to that tool. Let each tool\n   describe its own method in its own voice.\n7. **Artifacts & links** — Rippit's re-openable worksheet link(s); for the other tool,\n   state plainly there's no durable artifact (or link whatever persists).\n8. **Footer** — one muted line: run date · identical brief, isolated tool-pure agents ·\n   presented without a winner.\n\nDo **not** declare a winner, score the tools against each other, or nudge the user\ntoward one. The side-by-side itself is the deliverable — surface the differences (and\nthe agreements) faithfully and let the user draw the conclusion. Where one tool covered\na dimension the other couldn't, show that as a plain factual contrast, not as a point\nscored. If the user then asks which is better, answer that as a follow-up.\n\n## Principles\n\n- **Fairness is the product.** Identical brief, isolated agents, tool-pure access.\n  The comparison is only credible if neither side was advantaged in setup.\n- **Present, don't judge.** The skill produces a faithful side-by-side of the two\n  tools — each one's output and the process behind it — and stops there. Don't pick a\n  winner, score the tools against each other, or steer the user toward one; let them\n  decide and ask follow-ups. (If they explicitly ask which is better, that's a fair\n  follow-up to answer then.)\n- **Normalize the layout, not the substance.** Pull both tools into a shared,\n  parallel side-by-side so differences are easy to scan — but never let the tidy layout\n  disguise that one tool did less. If a tool sampled, couldn't classify individually, or\n  left a cell thin, show that plainly in its column (and in the empty/qualified cells)\n  rather than papering over it to make the table look balanced. The shape is shared; the\n  honesty about depth and coverage is not sacrificed to it.\n- **Show receipts.** Prefer findings backed by verifiable numbers and source links.\n- **Surface friction.** Document the operational realities each tool hit (timeouts,\n  sampling, reproducibility, schema/permission constraints) — they're often as\n  decision-relevant as the analysis quality.\n"
}