← ZimeCONTENT HISTORY
WHAT CHANGED
Update to Zime
Snapshot Oct 30, 2026 · 00:06 UTC · version 0.1.20
Collection source: downloaded plugin package.
First saved snapshot
No earlier snapshot is available to establish a change.
Save Zime and check future changes in Following.
Up to 10 plugins free · no card required.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "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.",
"included_files": [],
"name": "review-call",
"skill_md_contents": "---\nname: review-call\ndescription: \"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.\"\nlicense: MIT\nmetadata:\n zime:skill-id: af945a16-edc8-4838-ac82-6b315a89527d\n zime:tag: intelligence\n zime:roles: ae,se,cs\n zime:visibility: global\n zime:skill-version: \"1\"\n zime:marketplace-version: 0.1.20\n---\n\n# Review Call\n\nBefore 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`. It records which skill ran for Zime usage analytics. If the Zime connector is not available, skip this step and continue.\n\nEverything about **one** call or meeting, at whatever depth the question needs:\nthe record, the recap, or the exact words. One resolve step feeds all three, so\nyou never have to know which lookup you wanted before you ask.\n\n## Meetings vs calls\n\nOne tool covers both, because neither is a subset of the other:\n\n\n| | Scheduled meeting | Recorded call |\n| -------------- | ------------------ | ---------------------------- |\n| Exists in | calendar | recording + transcript store |\n| Time | past **or future** | always past |\n| Has transcript | never | yes |\n\n\nAn ad-hoc call that got recorded has **no** calendar entry. Anything upcoming,\nand any unrecorded past meeting, has **no** recording. A returned row carries\n`meeting_id`, `call_id`, and `has_transcript`, and any of the first two may be\nnull. That is information, not an error: a row with `call_id: null` is exactly\nwhy no transcript exists.\n\n## How It Works\n\n```\n┌─────────────────────────────────────────────────────────────────┐\n│ REVIEW CALL │\n├─────────────────────────────────────────────────────────────────┤\n│ STEP 1 — RESOLVE (always) │\n│ ✓ list_meetings: name/topic/attendee + date → one record │\n│ ✓ Window spans past AND future unless the user bounded it │\n│ ✓ Ambiguous → show candidates, ask, re-call pinned │\n├─────────────────────────────────────────────────────────────────┤\n│ STEP 2 — PICK THE DEPTH the question asked for │\n│ ▸ RECORD when / who / recorded? → stop after Step 1 │\n│ ▸ RECAP what happened, decided → ask_zime (default) │\n│ ▸ VERBATIM exact words, a quote → get_transcript │\n│ Asked for two? Deliver both, recap first. │\n├─────────────────────────────────────────────────────────────────┤\n│ NOT THIS SKILL (route away) │\n│ ✗ Prep for an UPCOMING call → call-prep │\n│ ✗ Action items / commitments → actions-commitments │\n│ ✗ The follow-up email → follow-up │\n│ ✗ Patterns across MANY calls → competitive-intelligence │\n│ ✗ Today's whole schedule → daily-briefing │\n├─────────────────────────────────────────────────────────────────┤\n│ LOCAL FALLBACK (no zime-mcp) │\n│ ~ Read a transcript or calendar export the user provides │\n└─────────────────────────────────────────────────────────────────┘\n```\n\n## Usage\n\n```\n@review-call <company, topic, or attendee> [+ when] [+ what you want]\n```\n\nIn the ChatGPT desktop app you can also type `/review-call`.\n\nReview the call the user named, at the depth they asked for.\n\n## Choosing the depth\n\nRead it off the question. When it is genuinely ambiguous, give the recap and\noffer the other two, rather than asking first.\n\n\n| The user asked | Depth | Stop at |\n| ---------------------------------------------------------------- | -------- | ---------------- |\n| \"when is my Acme call\", \"who was on the demo\", \"was it recorded\" | Record | Step 1 |\n| \"what happened\", \"recap that call\", \"what did we agree\" | Recap | `ask_zime` |\n| \"exact words\", \"what did they say about pricing\", \"a quote\" | Verbatim | `get_transcript` |\n\n\nNever return a transcript when a recap was asked for. A transcript is large\nand burns context that the rest of the conversation needs.\n\n## Routing\n\n- Getting ready for an upcoming call → `call-prep`.\n- Extracted commitments and owners → `actions-commitments`.\n- A drafted follow-up email → `follow-up`.\n- Themes across many calls → `competitive-intelligence`.\n- Today's or this week's schedule → `daily-briefing`.\n- The deal or account behind the call → `review-account`.\n\n## What I Need From You\n\nWho or what the call was about, plus a date hint if you have one. A date hint\nhelps a lot but is not required: the default window looks both back and\nforward, because \"my Acme meeting\" can just as easily mean last week's or\ntomorrow's.\n\n## MCP mode (required when zime-mcp is connected)\n\n**Required tools:** `list_meetings` (always), then `ask_zime` or\n`get_transcript` depending on depth.\n\nAnswering from memory or from earlier in the chat while these tools are\navailable is a failure of this skill. A remembered \"quote\" is not a quote, and\na remembered attendee list is not a record.\n\n### Step 1 — resolve the call\n\nArguments for `list_meetings`:\n\n- `query` — words identifying the call: company, attendee, or topic. Keep time\nwords OUT of this field.\n- `call_id` / `meeting_id` — pin an exact record from a prior\n`multiple_matches` response. Never invent one.\n- `start_date` / `end_date` — YYYY-MM-DD, inclusive. Every time hint goes\nhere. Convert \"yesterday\", \"last week\", \"tomorrow\" to real dates yourself.\n- `recorded` — set `true` when the depth is Recap or Verbatim, since only\nrecorded calls can supply either.\n\n**Example** — \"who was on the Northwind demo last week?\":\n\n```json\n{ \"query\": \"Northwind demo\", \"start_date\": \"2026-08-04\", \"end_date\": \"2026-08-10\" }\n```\n\nOutcomes:\n\n- `{\"status\": \"resolved\", \"data\": {...}}` — continue to the depth you picked.\n- `{\"status\": \"multiple_matches\", \"candidates\": [...]}` — show candidates with\ntheir dates so they can be told apart, ask which one, re-call pinned. Never\nguess. \"The latest one\" → take the newest.\n- `{\"status\": \"no_match\", \"candidates\": [...]}` — nothing matched in the\nwindow. This does **not** mean the call doesn't exist; the most common cause\nis a date window that excludes it. Say that, show near-misses, offer to\nwiden the range. Never substitute a different call.\n- An error — `{\"error\": \"<CODE>\", \"message\": \"<sentence>\"}`. Show the user\nthe message. `INTERNAL_ERROR` retry once; `TIMEOUT` narrow the window and\nretry; `CREDIT_LIMIT` stop and relay the message; `UNAUTHORIZED` /\n`FORBIDDEN` means reconnect or lack of access; `INVALID_ARGUMENT` means\nmalformed dates, fix and re-call.\n\nA resolved row with `has_transcript: false` ends Recap and Verbatim here. Say\nwhich case it is, upcoming or unrecorded, and don't imply a transcript could\nbe fetched.\n\n### Step 2a — Recap, via `ask_zime`\n\n> `ask_zime` routes to Zime's agent and has no `call_id` argument, so name the\n> call (title and date) in the question text. Writing the recap yourself from a\n> fetched transcript while `ask_zime` is available is a failure of this skill:\n> the agent also sees the call's extracted signals and CRM linkage, which a raw\n> transcript does not carry.\n\n```json\n{ \"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.\" }\n```\n\nResolve pronouns to real names; the agent has no memory of this conversation.\nIf the agent declines or returns nothing, say so plainly and don't fill the gap\nfrom the transcript yourself.\n\n### Step 2b — Verbatim, via `get_transcript`\n\nArguments: `query`, or `call_id` pinned from Step 1, plus `start_date` /\n`end_date`. Prefer the pinned `call_id` — you already resolved it.\n\nThis call fetches a large payload, so a timeout is a real possibility. If it\nfails twice, say so plainly rather than filling in from memory.\n\n## Output\n\n### Record\n\n```markdown\n**[Meeting title]** · [date, time]\n\n| Field | Value |\n|---|---|\n| Attendees | [names / emails] |\n| Linked deal | [deal name, or none] |\n| Recorded | [yes / no] |\n| Transcript | [available / not available] |\n| Call ID | `[call_id]` (absent if not recorded) |\n| Meeting ID | `[meeting_id]` (absent if ad-hoc) |\n\n_Live meeting record via Zime._\n```\n\nRelay fields as returned, no inference. Keep the ID lines: `call-prep` pins to\n`meeting_id`, and the other depths pin to `call_id`.\n\n### Recap\n\nThe agent's recap **is** the deliverable. This skill adds only the envelope:\n\n```markdown\n**Recap — [call title]** · [date] · [attendees]\n**Linked deal:** [deal name, or none]\n\n[the agent's returned recap, relayed as-is]\n```\n\nRelay it as-is. Don't re-rank sections, condense, or drop items; if it returned\nfive action items, deliver five. Preserve timestamps, owner names and severity\nmarkers, which are the parts a rep acts on. Don't add sections the agent didn't\nreturn.\n\n### Verbatim\n\n```markdown\n**Transcript — [call title]** · [date] · [duration if returned]\n**Attendees:** [names]\n**Linked deal:** [deal name, or none]\n\n---\n\n[full transcript text, verbatim as returned]\n```\n\nRelay the transcript **verbatim**. Don't clean it up, re-punctuate, condense or\nreorder; its value is that it is exactly what was said. If it is long, deliver\nit as-is rather than summarizing unprompted. Never merge two calls' transcripts\ninto one answer.\n\n### The rule that spans all three\n\nAnything you present in quotation marks must have come from `get_transcript`,\nnever from the recap agent's paraphrase. If the user wants an exact quote and\nyou only ran the recap, fetch the transcript.\n\n### Rendering\n\nRender the **header block** of any depth as the short labelled markdown lines\nin the templates above, so the reader can see at a glance which call this is.\n\n**A transcript body stays plain text below it.** No re-wrapping, no re-styling\nof speaker turns, no truncation. A long transcript is easier to read and copy\nas plain text.\n\n## Tips\n\n1. **Time words go in the date fields** — \"the Acme call yesterday\" resolves\n better as `query: \"Acme\"` plus a one-day range.\n2. **Narrow the window before asking for verbatim** — transcripts are big, and\n the wrong one is costly.\n3. **A wrong date guess causes a miss, not a wrong answer.** That's deliberate.\n If nothing matched, widen the window rather than trusting a guessed date.\n4. **Attendee names work**, not just company or topic.\n5. **Recorded only** for recap and verbatim. An unrecorded meeting can't supply\n either, however recent.\n6. **One call at a time.** For themes across many calls use\n `competitive-intelligence`.\n\n## Local mode (only when no zime-mcp server is connected)\n\nIf the user provides a transcript (`.txt`, `.vtt`, `.json`, `.md`), answer from\nthat file only, and open with one line saying so: a local recap has none of the\ncall's extracted signals or CRM linkage. If they provide a calendar or call\nexport (`.csv`), look the row up there. Mark gaps as gaps rather than inferring\ndecisions that were never stated. No file and no connection → say so rather\nthan reconstructing what was probably said.\n\n## What this sends where\n\nMCP mode sends the query words and date range to `list_meetings`, then either\nthe recap question naming the call to `ask_zime`, or the pinned `call_id` to\n`get_transcript`. Local mode reads only the file the user provided. At the\nstart, the skill calls the Zime connector tool `skill_used`, which records\nthe skill's id, version and name with your user and session in Zime's usage\nlog.\n\n## Related Skills\n\n- **call-prep** — get ready for an upcoming call\n- **actions-commitments** — the open items, across calls\n- **follow-up** — the email that follows the recap\n- **review-account** — the deal or account this call belongs to\n"
}SHA-256 of public snapshot: 67a17588dcd0fe296c8569fb51cd759e0cf36cefb03b5e75a8fdfbced8905c95