Agent Performance Review

## First run — make it yours

Before reviewing anything, interview the user one question at a time so the review fits their team and data. Then restate the filled-in bindings for confirmation and run. On later runs, reuse these bindings unless the user asks to change them.

1. Which agent do you want to review, and how are they identified in your ticket data (account name, id, or a sign-off alias I should watch for)? → {{agent_identifier}}
2. What time period should I review? You can give exact dates or a relative phrase like 'last month' and I'll resolve it against today. → {{review_period}}
3. Do you already have a specific angle in mind — a product area or a suspected pattern — that I should shape the write-up around, or should I review everything evenly? → {{review_angle}} (optional; if not set, review the full population evenly)
4. Which QA dimensions should I score each ticket against, or should I use a standard rubric of tone, loyalty, issue identification, info relevance, and accuracy vs. your knowledge base? → {{qa_rubric}}

# Agent Performance Review

## What this skill does

Someone names an agent ({{agent_identifier}}) and a time period ({{review_period}}), sometimes with a specific angle already in mind ({{review_angle}}). Your job is to turn their real tickets from that period into a grounded, written verdict: what this agent does well, what they should work on, and the actual conversations that prove it — then stay useful afterward, because the first question is rarely the only one. Keep the worksheet you built around, and only add new judgments when the existing ones can't answer the new question.

The deliverable is a chat answer, not a deployed tool — a written answer with clickable links back to real tickets. Offer to save it as a doc if the user wants something to paste into a 1:1 doc, but don't create a file unprompted.

## Step 0: Find your connectors

You need two connectors: a **Rippit-style** support-analytics server (`list_data_sources`, `describe_table`, `describe_column`, `create_worksheet`, `enrich_worksheet`, `get_enrich_status`, `read_table`, `aggregate_table`, and ideally `pivot_table`) and an **Intercom-style** server (`search_conversations`, `get_conversation`, `search_articles`, `get_article`). Tool names will be prefixed `mcp__<some-id>__`. If either is missing, tell the user directly which one and that it must be connected first — don't fake the analysis from general knowledge.

## Step 1: Pin down agent, period, and (optional) angle

Resolve explicit start/end dates from {{review_period}} against today before touching Rippit. Resolve *who* {{agent_identifier}} is with care: use `describe_column` (or equivalent) on the agent-identifying column to find candidate matches; if more than one plausible match comes back, ask the user which one. Agents may sign or introduce themselves under a different first name than their account name — attribute authorship structurally (author field / whose turn it is), never by string-matching a name in the text. If you confirm an alias, carry it forward into your Step 3 enrichment instructions.

If {{review_angle}} was given, note it to shape the write-up, but still review the full ticket population first rather than filtering it away, since a narrow filter here would bias your read before you've looked.

## Step 2: Build the worksheet

1. `list_data_sources` to find the right ticket/conversation table for this Rippit instance.
2. `describe_table` on it. Find: the agent-identifying column, the ticket/conversation date column, the conversation-id column (to link back to real tickets), and any topic/category/product-area column (needed later for scoped follow-ups). Schemas vary; don't assume field names from a prior run. If there are multiple date columns, prefer the *opened/created* one for "tickets from period X" — a last-activity field silently pulls in unrelated old tickets merely touched during the window. Sanity-check the resulting count. Also, an agent-identifying column often means "was present on the ticket" (routing, hand-offs, bots), not "wrote a reply" — when you report a population size, make sure N reflects tickets with a real substantive reply from this agent, and if that gap is large, say so.
3. `create_worksheet` filtered to that agent and date range (`where` on the agent column, `BETWEEN` on the date column). Cover the full population; only apply a `sampleRows`/`rowLimit` cap if the matched set is large enough that full enrichment would be slow, and if you do sample, say so plainly.

## Step 3: Enrich against the QA rubric (one batched call)

Rate every ticket against {{qa_rubric}}. Write grounded, specific instructions with an explicit "insufficient info" catch-all per dimension, substituting the agent's name/alias. Put every column in one `enrich_worksheet` call; cost scales with rows, not columns. Also pass any sentiment/effort/dissatisfaction-driver columns the table already has as `contextColumns` — free grounding for the model and for your customer-impact framing later. Poll `get_enrich_status` until `done: true`.

## Step 4: Turn ratings into a written verdict

1. `aggregate_table` grouped by each rating column to see the distribution — which dimensions skew strong, which skew weak.
2. Pick 2-3 real strengths and 2-3 real opportunities based on that distribution — not a fixed quota. If four dimensions are strong and one is weak, say that plainly instead of padding.
3. For each finding, `read_table` filtered to the rows behind it and pull 2-3 concrete examples: the verbatim quote, the rationale, the conversation id. Build a real Intercom link for each (`https://app.intercom.com/a/inbox/<workspace>/inbox/conversation/<id>` — confirm the workspace segment via `get_conversation` or by asking). Always write it as a markdown link with descriptive text — `[Open ticket <id> in Intercom](<url>)` — never a bare URL. The `<id>` in the link text must exactly match the id in the URL (the conversation's `external_id`).
4. Write the answer: a short prose lead-in on scope (agent, dates, ticket count), then strengths and opportunities each as their own bulleted list — one bullet per finding. Every bullet needs either a verbatim quote or a real aggregate number, plus a markdown link to the specific ticket. If a dissatisfaction-driver or sentiment-shift column was available, fold in a brief customer-impact bullet.
5. Only produce a saved file if the user asks to keep or share one (read the docx skill first). Otherwise the chat answer is the deliverable.

## Step 5: Keep the thread open for follow-up questions

The worksheet from Step 2 stays valid for the rest of the conversation. Treat any later question about the same agent and period as a continuation.

1. If it's answerable from what's already enriched (e.g. a rating column plus a topic column), just `aggregate_table` / `read_table` / `pivot_table` against the existing worksheet, filtered to the slice, and answer directly. Don't rebuild.
2. If it needs a judgment you haven't captured, add exactly the new column(s) via `enrich_worksheet`, scoped with `where` to just the relevant subset. Write grounded instructions with an explicit "insufficient info" catch-all.
3. Poll `get_enrich_status`, then `read_table` to pull the matching tickets — quotes, ids, Intercom links — and answer with those examples as a bulleted list, each bullet carrying a quote and a proper markdown link. A follow-up answer with no examples is a bad answer here.
4. If the user keeps narrowing into the same subset across several questions, that's the pattern the `rippit-double-click` skill is built for — consider a child worksheet over just that subset. Use it if installed; otherwise keep filtering the existing worksheet.

## A note on trust

Don't let a rating column stand in for evidence. Every claim needs a ticket behind it where you can point to what the agent actually wrote. If a follow-up can't be answered with real examples (too few matching tickets, ambiguous scope, connector error), say that plainly instead of generalizing from a training-data impression.