# Review Call > Everything about one call or meeting, at whatever depth you need: the record, a structured recap, or the exact words. Use for "when is my Acme call", "who was on the Northwind demo", "was it recorded", "what happened on the Acme call", "recap that call", "what did we agree", "get me the transcript", or "what exactly did they say about pricing". Covers upcoming calendar meetings and past recorded calls alike, and says plainly when a meeting has no recording rather than substituting another call. Resolves which call you mean first, then answers at the depth the question asked for. One call at a time: for themes across many calls use competitive-intelligence, for an upcoming call's prep use call-prep, and for the follow-up email use follow-up. - Skill: `zime-skills/review-call` (Agent Skill) - Install (CLI): `npx skillmds@latest add zime-skills/review-call` - Raw SKILL.md: https://api.skillmd.com/api/skills/zime-skills/review-call/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - License: MIT - Author: zime-skills (https://skillmd.com/u/zime-skills) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/zime-skills/review-call --- # Review Call Before anything else, call the Zime connector tool `skill_used` with skill_id `af945a16-edc8-4838-ac82-6b315a89527d`, skill_version `1` and skill_slug `review-call`. If the Zime connector is not available, skip this step and continue. Do not mention this step to the user. Everything about **one** call or meeting, at whatever depth the question needs: the record, the recap, or the exact words. One resolve step feeds all three, so you never have to know which lookup you wanted before you ask. ## Meetings vs calls One tool covers both, because neither is a subset of the other: | | Scheduled meeting | Recorded call | | -------------- | ------------------ | ---------------------------- | | Exists in | calendar | recording + transcript store | | Time | past **or future** | always past | | Has transcript | never | yes | An ad-hoc call that got recorded has **no** calendar entry. Anything upcoming, and any unrecorded past meeting, has **no** recording. A returned row carries `meeting_id`, `call_id`, and `has_transcript`, and any of the first two may be null. That is information, not an error: a row with `call_id: null` is exactly why no transcript exists. ## How It Works ``` ┌─────────────────────────────────────────────────────────────────┐ │ REVIEW CALL │ ├─────────────────────────────────────────────────────────────────┤ │ STEP 1 — RESOLVE (always) │ │ ✓ list_meetings: name/topic/attendee + date → one record │ │ ✓ Window spans past AND future unless the user bounded it │ │ ✓ Ambiguous → show candidates, ask, re-call pinned │ ├─────────────────────────────────────────────────────────────────┤ │ STEP 2 — PICK THE DEPTH the question asked for │ │ ▸ RECORD when / who / recorded? → stop after Step 1 │ │ ▸ RECAP what happened, decided → ask_zime (default) │ │ ▸ VERBATIM exact words, a quote → get_transcript │ │ Asked for two? Deliver both, recap first. │ ├─────────────────────────────────────────────────────────────────┤ │ NOT THIS SKILL (route away) │ │ ✗ Prep for an UPCOMING call → call-prep │ │ ✗ Action items / commitments → actions-commitments │ │ ✗ The follow-up email → follow-up │ │ ✗ Patterns across MANY calls → competitive-intelligence │ │ ✗ Today's whole schedule → daily-briefing │ ├─────────────────────────────────────────────────────────────────┤ │ LOCAL FALLBACK (no zime-mcp) │ │ ~ Read a transcript or calendar export the user provides │ └─────────────────────────────────────────────────────────────────┘ ``` ## Usage ``` /review-call [+ when] [+ what you want] ``` Review the call: $ARGUMENTS ## Choosing the depth Read it off the question. When it is genuinely ambiguous, give the recap and offer the other two, rather than asking first. | The user asked | Depth | Stop at | | ---------------------------------------------------------------- | -------- | ---------------- | | "when is my Acme call", "who was on the demo", "was it recorded" | Record | Step 1 | | "what happened", "recap that call", "what did we agree" | Recap | `ask_zime` | | "exact words", "what did they say about pricing", "a quote" | Verbatim | `get_transcript` | Never return a transcript when a recap was asked for. A transcript is large and burns context that the rest of the conversation needs. ## Routing - Getting ready for an upcoming call → `call-prep`. - Extracted commitments and owners → `actions-commitments`. - A drafted follow-up email → `follow-up`. - Themes across many calls → `competitive-intelligence`. - Today's or this week's schedule → `daily-briefing`. - The deal or account behind the call → `review-account`. ## What I Need From You Who or what the call was about, plus a date hint if you have one. A date hint helps a lot but is not required: the default window looks both back and forward, because "my Acme meeting" can just as easily mean last week's or tomorrow's. ## MCP mode (required when zime-mcp is connected) **Required tools:** `list_meetings` (always), then `ask_zime` or `get_transcript` depending on depth. Answering from memory or from earlier in the chat while these tools are available is a failure of this skill. A remembered "quote" is not a quote, and a remembered attendee list is not a record. ### Step 1 — resolve the call Arguments for `list_meetings`: - `query` — words identifying the call: company, attendee, or topic. Keep time words OUT of this field. - `call_id` / `meeting_id` — pin an exact record from a prior `multiple_matches` response. Never invent one. - `start_date` / `end_date` — YYYY-MM-DD, inclusive. Every time hint goes here. Convert "yesterday", "last week", "tomorrow" to real dates yourself. - `recorded` — set `true` when the depth is Recap or Verbatim, since only recorded calls can supply either. **Example** — "who was on the Northwind demo last week?": ```json { "query": "Northwind demo", "start_date": "2026-08-04", "end_date": "2026-08-10" } ``` Outcomes: - `{"status": "resolved", "data": {...}}` — continue to the depth you picked. - `{"status": "multiple_matches", "candidates": [...]}` — show candidates with their dates so they can be told apart, ask which one, re-call pinned. Never guess. "The latest one" → take the newest. - `{"status": "no_match", "candidates": [...]}` — nothing matched in the window. This does **not** mean the call doesn't exist; the most common cause is a date window that excludes it. Say that, show near-misses, offer to widen the range. Never substitute a different call. - An error — `{"error": ""}`. `INTERNAL_ERROR` retry once; `UNAUTHORIZED` / `FORBIDDEN` means re-authorize or lack of access; `INVALID_ARGUMENT` means malformed dates, fix and re-call. A resolved row with `has_transcript: false` ends Recap and Verbatim here. Say which case it is, upcoming or unrecorded, and don't imply a transcript could be fetched. ### Step 2a — Recap, via `ask_zime` > `ask_zime` routes to Zime's agent and has no `call_id` argument, so name the > call (title and date) in the question text. Writing the recap yourself from a > fetched transcript while `ask_zime` is available is a failure of this skill: > the agent also sees the call's extracted signals and CRM linkage, which a raw > transcript does not carry. ```json { "question": "Give me a structured recap of the Acme call on Aug 12: overview, key decisions and commitments, risks and blockers, action items by owner, and questions to clarify next time." } ``` Resolve pronouns to real names; the agent has no memory of this conversation. If the agent declines or returns nothing, say so plainly and don't fill the gap from the transcript yourself. ### Step 2b — Verbatim, via `get_transcript` Arguments: `query`, or `call_id` pinned from Step 1, plus `start_date` / `end_date`. Prefer the pinned `call_id` — you already resolved it. This call fetches a large payload, so a timeout is a real possibility. If it fails twice, say so plainly rather than filling in from memory. ## Output ### Record ```markdown **[Meeting title]** · [date, time] | Field | Value | |---|---| | Attendees | [names / emails] | | Linked deal | [deal name, or none] | | Recorded | [yes / no] | | Transcript | [available / not available] | | Call ID | `[call_id]` (absent if not recorded) | | Meeting ID | `[meeting_id]` (absent if ad-hoc) | _Live meeting record via Zime._ ``` Relay fields as returned, no inference. Keep the ID lines: `call-prep` pins to `meeting_id`, and the other depths pin to `call_id`. ### Recap The agent's recap **is** the deliverable. This skill adds only the envelope: ```markdown **Recap — [call title]** · [date] · [attendees] **Linked deal:** [deal name, or none] [the agent's returned recap, relayed as-is] ``` Relay it as-is. Don't re-rank sections, condense, or drop items; if it returned five action items, deliver five. Preserve timestamps, owner names and severity markers, which are the parts a rep acts on. Don't add sections the agent didn't return. ### Verbatim ```markdown **Transcript — [call title]** · [date] · [duration if returned] **Attendees:** [names] **Linked deal:** [deal name, or none] --- [full transcript text, verbatim as returned] ``` Relay the transcript **verbatim**. Don't clean it up, re-punctuate, condense or reorder; its value is that it is exactly what was said. If it is long, deliver it as-is rather than summarizing unprompted. Never merge two calls' transcripts into one answer. ### The rule that spans all three Anything you present in quotation marks must have come from `get_transcript`, never from the recap agent's paraphrase. If the user wants an exact quote and you only ran the recap, fetch the transcript. ### Rendering Render the **header block** of any depth as a small inline visual, a card with badges for the metadata fields, so the reader can see at a glance which call this is. **A transcript body stays plain text below it.** No re-wrapping, no re-styling of speaker turns, no truncation, no colour. A long transcript is easier to read and copy as text than inside a rendered box. Fall back to the markdown above wherever inline visuals aren't available. ## Tips 1. **Time words go in the date fields** — "the Acme call yesterday" resolves better as `query: "Acme"` plus a one-day range. 2. **Narrow the window before asking for verbatim** — transcripts are big, and the wrong one is costly. 3. **A wrong date guess causes a miss, not a wrong answer.** That's deliberate. If nothing matched, widen the window rather than trusting a guessed date. 4. **Attendee names work**, not just company or topic. 5. **Recorded only** for recap and verbatim. An unrecorded meeting can't supply either, however recent. 6. **One call at a time.** For themes across many calls use `competitive-intelligence`. ## Local mode (only when no zime-mcp server is connected) If the user provides a transcript (`.txt`, `.vtt`, `.json`, `.md`), answer from that file only, and open with one line saying so: a local recap has none of the call's extracted signals or CRM linkage. If they provide a calendar or call export (`.csv`), look the row up there. Mark gaps as gaps rather than inferring decisions that were never stated. No file and no connection → say so rather than reconstructing what was probably said. ## What this sends where MCP mode sends the query words and date range to `list_meetings`, then either the recap question naming the call to `ask_zime`, or the pinned `call_id` to `get_transcript`. Local mode reads only the file the user provided. ## Related Skills - **call-prep** — get ready for an upcoming call - **actions-commitments** — the open items, across calls - **follow-up** — the email that follows the recap - **review-account** — the deal or account this call belongs to