Skill instructions
account-research9.46 KB
View saved version →
---
name: account-research
description: "Research a new prospect company before you reach out. Checks if they fit our ICP and who the buyers might be. Use for companies not yet in CRM. For existing accounts, use review-account instead."
license: MIT
metadata:
zime:skill-id: a996cb94-8af5-4b6d-ae1e-5bd2fe043782
zime:tag: research
zime:roles: ae,bdr
zime:visibility: global
zime:skill-version: "1"
zime:marketplace-version: 0.1.20
---
# Account Research
Before anything else, call the Zime connector tool `skill_used` with skill_id `a996cb94-8af5-4b6d-ae1e-5bd2fe043782`, skill_version `1` and skill_slug `account-research`. It records which skill ran for Zime usage analytics. If the Zime connector is not available, skip this step and continue.
Researches a company **before** there's a relationship. The entity isn't in
CRM, there are no calls to read, and no Zime signals exist for it — so this
skill is web research with one grounding call, not a workspace lookup.
## What makes this different from every other skill here
Every other skill in this plugin resolves an entity in Zime and delegates to
an agent. This one inverts that:
- **No resolve step.** The prospect isn't in our CRM. If they were, the user
wants `review-account`.
- **Web search is the primary source**, not a fallback.
- **`ask_zime` is called once, and not about the prospect.** It's called about
*us* — to pull our ICP definition and what our won customers look like, so
"do they fit" is measured against something real instead of a guess.
## How It Works
```
┌─────────────────────────────────────────────────────────────────┐
│ ACCOUNT RESEARCH │
├─────────────────────────────────────────────────────────────────┤
│ STEP 1 — GROUND THE BASELINE (once, about US) │
│ ✓ ask_zime: our ICP, our won-customer patterns │
├─────────────────────────────────────────────────────────────────┤
│ STEP 2 — RESEARCH THE PROSPECT (web search, primary) │
│ ✓ What they do, size, funding, customers │
│ ✓ Their GTM / CS motion — how they sell and support │
│ ✓ Buyers and likely champions │
│ ✓ Trigger events: funding, hiring, launches, reorgs │
├─────────────────────────────────────────────────────────────────┤
│ STEP 3 — SCORE THE FIT (against Step 1's baseline) │
│ ✓ ICP scorecard with evidence per dimension │
│ ✓ Recommended angle and entry point │
├─────────────────────────────────────────────────────────────────┤
│ NEVER │
│ ✗ Invented headcount, revenue, or funding figures │
│ ✗ A named "champion" with no source │
└─────────────────────────────────────────────────────────────────┘
```
## Usage
```
@account-research <company name or domain>
```
In the ChatGPT desktop app you can also type `/account-research`.
Research the prospect the user named.
## Routing
- An **existing CRM account**, or a deal already in flight — record, owner,
stage, risk → `review-account`. This skill is for companies not yet in CRM.
- A competitor rather than a prospect → `competitive-intelligence` (which
reads our calls, not the web).
- Building the outreach asset after research → `create-sales-asset`.
## What I Need From You
The company name, ideally with a domain. Helpful additions:
- **Who you'd be selling to** (CS leader, VP Sales, RevOps) — focuses the
buyer research
- **Why they're on your list** — inbound, a trigger event, a referral
If the company turns out to already be in CRM, say so and offer
`review-account` rather than researching them as new.
## MCP mode (when zime-mcp is connected)
**Required tool:** `ask_zime`, used once for the baseline.
### Step 1 — pull our own ICP baseline
```json
{ "question": "What is our ICP definition, and what do our won customers have in common — company size, industry, GTM motion, team structure, and the pains that made them buy?" }
```
Do this **first**. Without it, the fit assessment is the model's prior about what
a good customer looks like rather than ours. If `ask_zime` returns nothing
useful on ICP, say the fit assessment is unanchored and label the scorecard as
provisional — don't quietly substitute a generic B2B SaaS ICP.
Note: `ask_zime` cannot tell you anything about the prospect. It only sees our
workspace. Asking it about a company we've never spoken to will correctly
return nothing.
### Step 2 — web research
Run these searches and cite what you use:
1. `[company]` — homepage, what they sell, positioning
2. `[company] customers` / case studies — who they serve
3. `[company] funding` — stage, amount, investors, date
4. `[company] careers sales` OR `careers customer success` — GTM motion and
team shape; open roles are the strongest public signal of how they sell
5. `[company] leadership` — likely buyers and their backgrounds
6. `[company] news` — trigger events in the last 90 days
7. `[buyer name] LinkedIn` — background for named individuals
Extract only what the sources say. If a source doesn't state headcount, the
scorecard says headcount is unknown.
## Output
```markdown
# Prospect research: [Company]
**Researched:** [date] · **Sources:** web search[ + Zime ICP baseline]
## Quick take
[3 sentences: who they are, why they might need us, the sharpest angle.]
## Company profile
| Field | Value | Source |
|---|---|---|
| What they do | [description] | [link] |
| Size | [headcount, or unknown] | [link] |
| Funding | [stage, amount, date] | [link] |
| Customers | [who they serve] | [link] |
## How they sell and support
| Dimension | What we found | Source |
|---|---|---|
| Sales motion | [direct / channel / PLG / hybrid] | [link] |
| Team shape | [dedicated AEs? generalists? CS function?] | [link] |
| Tooling | [CRM, call recorder, support tool if public] | [link] |
| Scale pressure | [account:CSM ratio, growth signals] | [link] |
## Likely buyers
### [Name] — [Title]
- **Background:** [prior roles] · [LinkedIn]
- **Why they'd care:** [tie to a pain we solve]
## ICP fit
**Verdict: [strong fit / partial fit / poor fit / insufficient data]**
| ICP dimension (ours) | Their signal | Fit |
|---|---|---|
| [dimension from Step 1] | [evidence + source] | ✅ / ⚠️ / ❌ / ❓ |
**Why:** [2-3 sentences against the baseline, not against generic ideals.]
## Trigger events
- **[event]** — [date] — [why it creates an opening] — [source]
## Recommended approach
- **Entry point:** [person and why them]
- **Opening hook:** [the specific thing to lead with]
- **Discovery questions:** [3, aimed at the gaps marked ❓ above]
## Gaps
- [what we could not establish, and how to find out]
## Sources
- [title](url)
```
### Rules
- **Every factual row cites a source.** A company profile without links is
indistinguishable from a guess.
- **Unknown is a valid cell.** Never fill headcount, revenue, or funding with
a plausible number — a made-up figure in a research brief gets quoted back
in a pitch.
- **A named buyer needs a source.** No inventing a "likely champion".
- **Score against Step 1's baseline, not a generic ICP.** If the baseline is
missing, label the verdict provisional.
- **`insufficient data` is a real verdict.** Prefer it to a confident score
built on two thin sources.
- Keep the Gaps section — it becomes the discovery agenda.
## Tips
1. **Give the domain** — disambiguates common company names immediately.
2. **Say who you'd sell to** — sharpens the buyer research considerably.
3. **Careers pages are the best public GTM signal** — who they're hiring tells
you how they sell.
4. **Already a customer?** You want `review-account`, not this.
## Standalone mode (no zime-mcp connected)
Web search alone still produces the full brief. Skip Step 1, and label the ICP
section provisional, stating plainly that fit was assessed without our own ICP
definition. Everything else is unchanged — this skill's primary source doesn't
depend on Zime.
## What this sends where
MCP mode sends one question about **our** ICP to the zime-mcp server — never
the prospect's name, since Zime has no data on them. Web searches send the
prospect's public name to the search tool. At the start, the skill calls the
Zime connector tool `skill_used`, which records the skill's id, version and
name with your user and session in Zime's usage log.
## Related Skills
- **review-account** — a company already in CRM
- **create-sales-asset** — build the outreach asset from this research
- **call-prep** — once the first meeting is booked
actions-commitments7.81 KB
View saved version →
---
name: actions-commitments
description: "Shows open action items and commitments. Who promised what, and by when. Works for one call, one deal, or a whole account."
license: MIT
metadata:
zime:skill-id: 65cb2c4b-4d72-4393-81b5-7546750abae2
zime:tag: execution
zime:roles: ae,cs
zime:visibility: global
zime:skill-version: "1"
zime:marketplace-version: 0.1.20
---
# Actions & Commitments
Before anything else, call the Zime connector tool `skill_used` with skill_id `65cb2c4b-4d72-4393-81b5-7546750abae2`, skill_version `1` and skill_slug `actions-commitments`. It records which skill ran for Zime usage analytics. If the Zime connector is not available, skip this step and continue.
Answers "what's still open?" with commitments that were actually made — who
owns each one and when it's due. The value here is that nothing is invented:
an unclaimed action with no owner is reported as unowned, not assigned to
whoever seems likely.
## How It Works
```
┌─────────────────────────────────────────────────────────────────┐
│ ACTIONS & COMMITMENTS │
├─────────────────────────────────────────────────────────────────┤
│ STEP 1 — RESOLVE SCOPE (this skill) │
│ ✓ One call → list_meetings → call_id │
│ ✓ One deal → list_deals → deal_id │
│ ✓ An account → list_deals / list_meetings for that account │
├─────────────────────────────────────────────────────────────────┤
│ STEP 2 — DELEGATE (Zime agent) │
│ + ask_zime, naming the call, deal, or account in the question │
│ + Agent extracts commitments, owners, dates from real calls │
├─────────────────────────────────────────────────────────────────┤
│ LOCAL FALLBACK (no zime-mcp) │
│ ~ Extract from a transcript file the user provides │
└─────────────────────────────────────────────────────────────────┘
```
## Usage
```
@actions-commitments <call, deal, or account> [+ when]
```
In the ChatGPT desktop app you can also type `/actions-commitments`.
Show the open commitments for the call, deal or account the user named.
## Routing
- A full recap of one call, not just its actions → `review-call`.
- The email that chases these items → `follow-up`.
- Deal risk and strategy, or pipeline-wide status across many deals, rather
than open items → `review-account`.
## What I Need From You
The scope — a call, a deal, or an account — and a time window if you want it
bounded ("this week", "since the QBR"). If the scope is ambiguous I'll ask
rather than guessing between a call and a deal.
## MCP mode (required when zime-mcp is connected)
**Required tools:** `list_meetings` and/or `list_deals` (resolve), plus
`ask_zime` (extract).
> `ask_zime` routes to Zime's global agent, with no separate id
> argument — name the call, deal, or account in the question text. Extracting
> commitments yourself from a fetched transcript while it's available is a
> failure of this skill: the agent also sees extracted signals and CRM
> linkage, and it distinguishes a firm commitment from an idea someone
> floated.
### Step 1 — resolve the scope
Pick the narrowest scope the request implies:
| Request shape | Resolve with | Then |
|---|---|---|
| "on the Acme call" | `list_meetings` (`recorded: true`) | name the call in the question |
| "on the Northwind deal" | `list_deals` | name the deal in the question |
| "what did I promise Globex" | `list_deals` for that account | name the account in the question |
`multiple_matches` → show candidates, ask, pin the id. Never guess.
`no_match` → say the window or naming likely excludes it; offer to widen.
### Step 2 — delegate the extraction
```json
{ "question": "List every commitment and action item from the Acme call on Aug 12: what was promised, who owns it, and the due date if one was stated. Separate our commitments from the customer's." }
```
or, for a deal or account arc:
```json
{ "question": "List the open action items and commitments across the Northwind deal: what was promised, by whom, when it was promised, and whether it has been closed out." }
```
Resolve pronouns to real names — the agent has no memory of this
conversation.
### Outcomes
- **A list of commitments** — deliver per Output below.
- **Nothing open** — say that plainly. "No open commitments found" is a valid
and useful answer; don't pad it with maybes.
- **An error** — `{"error": "<CODE>", "message": "<sentence>"}`. Show the user
the message. `INTERNAL_ERROR` retry once; `TIMEOUT` narrow the scope and
retry; `CREDIT_LIMIT` stop and relay the message; `UNAUTHORIZED` /
`FORBIDDEN` means reconnect or lack of access. If it fails twice, say so
and offer the local fallback.
## Output
Group by owner, because that's how the rep acts on it.
```markdown
**Open commitments — [scope]** · [window]
### Ours
| Commitment | Owner | Due | Source |
|---|---|---|---|
| [what was promised] | [name] | [date, or "not stated"] | [call, date] |
### Customer's
| Commitment | Owner | Due | Source |
|---|---|---|---|
| [what they promised] | [name] | [date, or "not stated"] | [call, date] |
### Unowned
| Commitment | Raised on | Note |
|---|---|---|
| [item with no clear owner] | [call, date] | needs an owner |
_Extracted from the workspace's calls via Zime._
```
Rules:
- **Never invent an owner.** If nobody claimed it, it goes under Unowned.
Guessing an owner creates a false accountability trail.
- **Never invent a due date.** "not stated" is the correct value when no date
was agreed — a plausible date read as real causes missed commitments.
- Keep the source (which call, what date) on every row; that's what makes an
item checkable.
- Distinguish ours from the customer's. A rep chasing their own list is a
different action from chasing the customer's.
- If the agent marked something already closed, either omit it or label it
closed — don't silently re-open it.
## Tips
1. **Narrow the scope** — one call is sharper than a whole account.
2. **"not stated" is the honest answer** for a missing date; treat it as a
prompt to go confirm.
3. **Unowned items are the real finding** — they're the ones that get dropped.
4. **Chase them with `follow-up`** once you know what's open.
## Local mode (only when no zime-mcp server is connected)
If the user provides a transcript, extract commitments from that file only,
using the same owner/date discipline. Open with one line saying the list
covers just that call, so items agreed elsewhere are missing by construction.
## What this sends where
MCP mode sends query words and dates (to `list_meetings`/`list_deals`), then
the extraction question naming the call, deal, or account (to `ask_zime`).
Local mode reads only the provided file. At the start, the skill calls the
Zime connector tool `skill_used`, which records the skill's id, version and
name with your user and session in Zime's usage log.
## Related Skills
- **follow-up** — the email that chases these
- **review-call** — the full picture of one call
- **create-sales-to-cs-handover** — commitments carried into the handover doc
call-prep8.37 KB
View saved version →
---
name: call-prep
description: "Builds a quick prep note before an upcoming call. Shows the biggest risk, and 2-3 things to do. Only works for your own upcoming meetings."
license: MIT
metadata:
zime:skill-id: dfeec687-3057-43fb-abc0-bb0c46256665
zime:tag: workflow
zime:roles: ae,se
zime:visibility: global
zime:skill-version: "1"
zime:marketplace-version: 0.1.20
---
# Call Prep
Before anything else, call the Zime connector tool `skill_used` with skill_id `dfeec687-3057-43fb-abc0-bb0c46256665`, skill_version `1` and skill_slug `call-prep`. It records which skill ran for Zime usage analytics. If the Zime connector is not available, skip this step and continue.
Gets a rep up to speed before a customer call. The prep-note agent builds the
note from the meeting's CRM deal and account, its external attendees, and the
relevant past calls — context no chat history can match. This skill's job is
to resolve the right meeting and deliver what the agent returns.
## How It Works
```
┌─────────────────────────────────────────────────────────────────┐
│ CALL PREP │
├─────────────────────────────────────────────────────────────────┤
│ STEP 1 — RESOLVE (this skill) │
│ ✓ list_meetings, forward-looking window │
│ ✓ Ambiguous → show candidates, ask, pin meeting_id │
├─────────────────────────────────────────────────────────────────┤
│ STEP 2 — DELEGATE (Zime prep-note agent) │
│ + prep_note builds the note from deal, account, attendees, │
│ and past calls — grounded in real workspace data │
│ + Returns the finished note; this skill does not rewrite it │
├─────────────────────────────────────────────────────────────────┤
│ LOCAL FALLBACK (no zime-mcp) │
│ ~ Assemble from a meeting-context file + past transcripts │
└─────────────────────────────────────────────────────────────────┘
```
## Usage
```
@call-prep <company or meeting> [+ when]
```
In the ChatGPT desktop app you can also type `/call-prep`.
Prep for the call the user named.
## Routing
- Anything about PAST calls (recaps, "what objections came up") →
`review-call`.
- Deal strategy not tied to one upcoming call ("how do I win this") →
`review-account`.
- "What meetings do I have?" is a schedule listing → `daily-briefing`.
- Use this skill only when there is an upcoming, scheduled call AND the user
wants to prepare for it.
## What I Need From You
The company or person, and a time hint if you have one ("tomorrow", "my
3pm"). If several upcoming meetings match, I'll show them and ask.
This only preps **your own** meetings — ones you organize or attend. If you
ask to prep someone else's call, I'll say so rather than guessing.
## MCP mode (required when zime-mcp is connected)
**Required tools:** `list_meetings` (resolve) and `prep_note` (generate).
Hand-building the note while `prep_note` is available is a failure of this
skill, even when the user gave you enough context to write something
plausible — the agent grounds every claim in the workspace's real calls and
CRM.
### Step 1 — resolve the meeting
Call `list_meetings` with a **forward-looking** window (an upcoming meeting
is by definition in the future; a past-only window will find nothing).
```json
{ "query": "Meridian", "start_date": "2026-08-13", "end_date": "2026-08-27" }
```
- `resolved` → take its `meeting_id` and go to Step 2.
- `multiple_matches` → show the candidates with their times, ask which one,
then use the chosen `meeting_id`. Never pick for the user.
- `no_match` → say there's no matching upcoming meeting in that window and
offer to widen it. Don't fall through to prepping a past call.
### Step 2 — delegate to the prep-note agent
Call `prep_note` with the resolved id.
```json
{ "query": "prep me for my Meridian call tomorrow", "calendar_event_id": "<meeting_id>" }
```
Keep `query` as the user's request, minimally rewritten, with the company and
any time hint intact. Unlike other Zime skills, time words BELONG in this
query — the agent uses them too. Never invent a company or time that wasn't
said.
### Outcomes
- **A prep note** (markdown) — deliver per Output below. If the same meeting
was prepped recently, Zime returns the stored note quickly instead of
regenerating; that reuse is by design, not staleness.
- **A candidate list** — if `prep_note` re-offers its own candidates (a
pinned id can be stale or not the rep's own meeting), show the fresh list
and pick again from it.
- **"You have no upcoming external meetings"** — nothing to prep; say so.
- **"Prep notes aren't configured for your workspace yet"** — generation
needs workspace setup; tell the user to ask their Zime admin.
- **"A prep note for this call is already being generated"** — another
request is mid-flight; wait a few seconds and call again once.
- **An error** — `{"error": "<CODE>", "message": "<sentence>"}`. Show the
user the message. `INTERNAL_ERROR` retry once; `CREDIT_LIMIT` stop and relay
the message; `UNAUTHORIZED` means reconnect. If it still fails, say plainly the
prep-note service couldn't be reached and offer the local fallback — never
silently substitute a hand-written note and present it as agent-backed.
## Output
The agent's note **is** the deliverable. This skill adds only a thin
envelope so the rep knows which meeting was prepped:
```markdown
**Prep — [meeting title]** · [date, time] · [attendees]
[the agent's returned note, relayed as-is]
```
Rules:
- Relay the returned markdown **as-is**. Every claim traces to the
workspace's calls and CRM, so don't rewrite, re-rank, condense, or
supplement it from other tools or memory.
- Keep every link it returns. An item without a link is presented without
one — silently, never with a "link unavailable" note.
- Don't append your own extra sections (agenda, discovery questions,
objection handling). If the agent didn't return it, it isn't grounded.
- If the resolved meeting isn't the one the user meant, re-resolve rather
than editing the note to fit.
## Tips
1. **Name the company and the time** — "Meridian tomorrow" resolves in one
step.
2. **Only your own meetings** — the agent can't prep a colleague's call.
3. **Recently prepped calls return instantly** — that's cached by design.
4. **Want a past call instead?** That's `review-call`.
## Local mode (only when no zime-mcp server is connected)
Build the note from files the user provides — a meeting-context block or
pasted calendar invite, optional past-call transcripts (`.txt`, `.vtt`,
`.json`, `.md`), and an optional CRM export (`.csv`). Follow
[references/call-prep-format.md](references/call-prep-format.md) exactly:
seven sections, skimmable in a minute, every claim sourced, gaps marked as
gaps ("No prior calls provided — ask the rep what's already been discussed")
instead of plausible filler. Open with one line saying the note was built
from provided files only, without live workspace data.
Sample inputs to try first: `assets/sample-meeting-context.txt` and
`assets/sample-past-call.txt` (both synthetic).
## What this sends where
MCP mode sends the query words and date range (to `list_meetings`), then the
user's request wording and a `calendar_event_id` (to `prep_note`). Local mode
reads only the files the user points at — nothing leaves the machine. At the
start, the skill calls the Zime connector tool `skill_used`, which records the
skill's id, version and name with your user and session in Zime's usage log.
## Related Skills
- **review-call** — the same account's past calls: record, recap or exact
words
- **review-account** — the deal behind this meeting
Referenced files: 3 — file references are metadata, not package contents.
competitive-intelligence9.22 KB
View saved version →
---
name: competitive-intelligence
description: "Shows what customers actually say about competitors. Where they come up, what they claim, and how we compare. Only uses real quotes from real calls."
license: MIT
metadata:
zime:skill-id: 97b63479-93dc-4cf2-9ee1-754a216267b4
zime:tag: intelligence
zime:roles: ae,se
zime:visibility: global
zime:skill-version: "1"
zime:marketplace-version: 0.1.20
---
# Competitive Intelligence
Before anything else, call the Zime connector tool `skill_used` with skill_id `97b63479-93dc-4cf2-9ee1-754a216267b4`, skill_version `1` and skill_slug `competitive-intelligence`. It records which skill ran for Zime usage analytics. If the Zime connector is not available, skip this step and continue.
Answers "what are customers actually saying about Competitor X?" from the
workspace's own calls. The value is that it's evidence from real
conversations, not what the internet says about a competitor — and the two are
often very different.
## The line this skill holds
General market knowledge about a competitor is the failure mode. What their
website claims, their published pricing, their reputation — none of that is
what this skill returns. If the corpus has nothing on a competitor, the answer
is "nothing in our calls mentions them", not a summary from training data.
That distinction is the whole point: a rep can act on "three customers raised
their SSO gap last quarter" and cannot act on "they're generally seen as
cheaper."
## How It Works
```
┌─────────────────────────────────────────────────────────────────┐
│ COMPETITIVE INTELLIGENCE │
├─────────────────────────────────────────────────────────────────┤
│ SCOPE FIRST (this skill decides which) │
│ ✓ "on the Acme call" → list_meetings, then name the call in the │
│ ask_zime question │
│ ✓ "across our deals" → ask_zime directly (no resolve needed) │
├─────────────────────────────────────────────────────────────────┤
│ DELEGATE (Zime agent) │
│ + Agent reads real calls, mentions, and extracted signals │
│ + Returns evidence with accounts and dates attached │
├─────────────────────────────────────────────────────────────────┤
│ NEVER │
│ ✗ Competitor facts from general knowledge │
│ ✗ A "typical" objection nobody actually raised │
├─────────────────────────────────────────────────────────────────┤
│ LOCAL FALLBACK (no zime-mcp) │
│ ~ Scan a transcript file the user provides │
└─────────────────────────────────────────────────────────────────┘
```
## Usage
```
@competitive-intelligence <competitor> [+ scope] [+ when]
```
In the ChatGPT desktop app you can also type `/competitive-intelligence`.
Report competitive intel on the competitor the user named.
## Routing
- Objections on ONE deal, competitor or not, or win/loss rates and pipeline
totals → `review-account`.
- A recap of one call that happened to mention a competitor → `review-call`.
- Turning competitive evidence into a battlecard or talking points →
`create-sales-asset`.
## What I Need From You
The competitor name. Scope and window help: "on the Acme call" is a different
question from "across our deals this quarter", and this skill routes them
differently.
## MCP mode (required when zime-mcp is connected)
**Required tools:** `ask_zime` (all scopes). For single-call scope also
`list_meetings` first, to name the exact call in the question.
> `ask_zime` routes to Zime's global agent across the whole accessible
> corpus, with no separate scoping argument — narrow it by naming the call,
> account, or window inside the question text. Answering from general
> knowledge about the competitor while it's available is a failure of this
> skill.
### Choosing the scope
| Request shape | Path |
|---|---|
| "did Competitor X come up on the Acme call" | `list_meetings` to confirm the call, then name it in the question |
| "where is Competitor X showing up" | `ask_zime` directly |
| "how do we position against them in deals we won" | `ask_zime` directly |
| "what did they say about them last quarter" | `ask_zime` with the window in the question |
Don't narrow to one call when the question is corpus-wide — that would
silently answer a much smaller question than the one asked.
### Cross-corpus
```json
{ "question": "Where has Initech come up in our calls in the last quarter, what did customers say about them, and how did we position against them?" }
```
Send the question close to verbatim with the competitor named explicitly and
the time window stated in the text — `ask_zime` has no memory of this
conversation and no separate date parameters.
### Single call
Resolve first, so the call is named correctly:
```json
{ "query": "Acme", "start_date": "2026-08-01", "end_date": "2026-08-13", "recorded": true }
```
then name it in the question:
```json
{ "question": "On the Acme call on Aug 12, did Initech or any competitor come up? What exactly was said, and how did we respond?" }
```
### Outcomes
- **Evidence returned** — deliver per Output below.
- **Nothing found** — say plainly that nothing in the accessible calls
mentions this competitor, and stop. Do **not** supplement with what you know
about them from elsewhere. A clean "no mentions" is a real answer and often
a useful one.
- **An error** — `{"error": "<CODE>", "message": "<sentence>"}`. Show the user
the message. `INTERNAL_ERROR` retry once; `TIMEOUT` narrow the scope or
window and retry; `CREDIT_LIMIT` stop and relay the message; `UNAUTHORIZED` /
`FORBIDDEN` means reconnect or lack of access. If it fails twice, say so
and offer the local fallback.
## Output
Evidence-first, because a claim without an account and a date can't be used in
front of a customer.
```markdown
**Competitive intel — [competitor]** · [scope] · [window]
### Where they came up
| Account | What was said | When |
|---|---|---|
| [account] | [what the customer actually said] | [date] |
### Recurring patterns
- **[pattern]** — [accounts it appears in] — [what it means]
### How we're positioned
[the agent's read, relayed as-is]
### Gaps
- [dimension the corpus had nothing on]
_From the workspace's own calls via Zime. Not market research._
```
Rules:
- Every row needs an **account and a date**. An undated competitive claim is
not usable and shouldn't be presented as intel.
- Relay what the customer said close to the agent's phrasing — don't sharpen
it into a punchier line. "They said the integration worried them" is not
"they're losing on integration".
- Anything in quotation marks must come from `get_transcript`, not from an
agent's paraphrase. Fetch it if the rep needs a literal quote.
- Keep the Gaps section. Where the corpus is silent is itself competitive
intelligence — it usually means reps aren't asking.
- Never blend in general knowledge about the competitor, even to "add
context". Label the boundary explicitly.
## Tips
1. **Scope it deliberately** — one call and the whole corpus are different
questions with different answers.
2. **Put the window in the question** for `ask_zime` — it has no date
parameters.
3. **"No mentions" is a finding** — it can mean the competitor isn't in play,
or that nobody's asking. Both are actionable.
4. **Need a battlecard?** Pass this evidence to `create-sales-asset`.
## Local mode (only when no zime-mcp server is connected)
If the user provides transcripts, scan those files only for competitor
mentions. Open with one line saying the scan covers just the provided files,
so this is not a corpus-wide view. Same rule: no general knowledge about the
competitor, only what the files contain.
## What this sends where
MCP mode sends the question text, with any call/account/window named inside
it (to `ask_zime`), and query words plus dates when confirming a call
first (to `list_meetings`). Local mode reads only the provided files. At the
start, the skill calls the Zime connector tool `skill_used`, which records the
skill's id, version and name with your user and session in Zime's usage log.
## Related Skills
- **create-sales-asset** — turn this evidence into a battlecard
- **review-account** — competitor dynamics on one specific deal
- **review-call** — the exact quotable line from one call
create-sales-asset11.4 KB
View saved version →
---
name: create-sales-asset
description: "Builds a sales asset from real customer evidence only, never made up facts. Covers account review decks (as a slide-by-slide outline), one-pagers, battlecards, case studies, and objection talking points. Always an internal draft, not customer-ready."
license: MIT
metadata:
zime:skill-id: 33b3e084-8df2-40bd-b91f-1d5199dd9a14
zime:tag: communication
zime:roles: ae,marketing
zime:visibility: global
zime:skill-version: "1"
zime:marketplace-version: 0.1.20
---
# Sales Asset Builder
Before anything else, call the Zime connector tool `skill_used` with skill_id `33b3e084-8df2-40bd-b91f-1d5199dd9a14`, skill_version `1` and skill_slug `create-sales-asset`. It records which skill ran for Zime usage analytics. If the Zime connector is not available, skip this step and continue.
Turns "build me an account review for Acme" into a draft in our house format.
This skill owns the **structure and framing**; the agents own the **facts**. It
never originates a metric, a quote, or a "customer said" line.
## The hard rule
Every factual claim in the asset — a metric, a quoted line, a stated customer
outcome, a competitive win — must trace to something a tool returned in **this
conversation**, with the account and date attached. If a needed fact wasn't
returned, the asset marks the gap open rather than filling it with a plausible
number or a paraphrased "customers typically say" line.
This is the one rule the skill cannot bend. Arranging real tool output is the
job; inventing supporting evidence is a failure of it — even when the invented
line looks exactly like something a customer would say. An asset is the
deliverable most likely to be pasted into a customer-facing deck, which is
precisely why fabrication here is the most expensive.
## How It Works
```
┌─────────────────────────────────────────────────────────────────┐
│ SALES ASSET BUILDER │
├─────────────────────────────────────────────────────────────────┤
│ STEP 1 — RESOLVE THE SUBJECT │
│ ✓ list_accounts (account asset) or list_deals (deal asset) │
├─────────────────────────────────────────────────────────────────┤
│ STEP 2 — GATHER DATED EVIDENCE │
│ + ask_zime — signals, risks, expansion, outcomes, patterns │
│ + get_transcript — the exact line, when a real quote is needed │
├─────────────────────────────────────────────────────────────────┤
│ STEP 3 — ASSEMBLE (house format) │
│ ✓ references/deck-grammar.md — the section order we use │
│ ✓ Every row carries evidence + date + account │
├─────────────────────────────────────────────────────────────────┤
│ STEP 4 — DELIVER │
│ ✓ Account review deck → slide-by-slide outline in markdown │
│ ✓ Every other asset type → markdown, ready to paste │
├─────────────────────────────────────────────────────────────────┤
│ ALWAYS │
│ ! Internal draft. Needs review before it leaves the building. │
└─────────────────────────────────────────────────────────────────┘
```
## Usage
```
@create-sales-asset <asset type> for <account, deal, or competitor>
```
In the ChatGPT desktop app you can also type `/create-sales-asset`.
Build the asset the user asked for.
## Routing
- A pipeline stat, risk or strategy on one deal, or one CRM fact, with no
asset to build → `review-account`.
- A recap of one call, or the email after it → `review-call` / `follow-up`.
- Competitive evidence gathering with no asset yet →
`competitive-intelligence` (then come back here to shape it).
- Researching a **prospect** we haven't sold to → `account-research`.
## What I Need From You
**Which asset**, and **what it's about**:
| Asset | Subject | Typically needs |
|---|---|---|
| Account review deck | one account | signals, risks, expansion, open items |
| Proof-point one-pager | one account/deal | outcomes with numbers, a real quote |
| Battlecard section | a competitor | how we position, objections, wins |
| Case-study writeup | one customer | before/after, outcomes, a quote |
| Objection talking points | an objection theme | how it was handled successfully |
If the user names an audience ("for the CS team", "for the QBR"), keep it —
it changes emphasis, not evidence.
## MCP mode (required when zime-mcp is connected)
**Required tools:** `list_accounts` / `list_deals` (resolve), `ask_zime`
(evidence), `get_transcript` (exact quotes).
> Hand-building a proof point from general product knowledge while
> `ask_zime` is available is a failure of this skill: only it sees the
> workspace's real calls, CRM records, and extracted signals.
### Step 1 — resolve the subject
```json
{ "query": "Acme" }
```
`multiple_matches` → show candidates, ask, pin. Never guess: building an asset
about the wrong account wastes the whole asset.
Skip this step for a competitor-only battlecard — go straight to `ask_zime`.
### Step 2 — gather evidence, asking for dates explicitly
Name the account or deal in the question itself, since `ask_zime` has no
separate id argument:
```json
{ "question": "For the Acme account: what expansion signals, churn risks, and open commitments appear in our calls? For each one give the evidence, the call date, and who said it." }
```
Cross-account or competitive:
```json
{ "question": "How do we position against Initech in deals we have won, and what objections about them recur? Include the account and date for each example." }
```
**Always ask for the date and the speaker.** An undated claim can't go in an
asset — see the deck grammar. If the agent returns claims without dates, ask
once more for them rather than shipping undated rows.
### Step 3 — exact quotes only via `get_transcript`
If the asset needs something in quotation marks:
```json
{ "query": "Acme renewal", "start_date": "2026-06-01", "end_date": "2026-06-30" }
```
A quote in the asset must come from here. Putting an agent's paraphrase inside
quotation marks is fabrication with extra steps.
### Outcomes
Each tool returns the usual shapes — `resolved` / `multiple_matches` /
`no_match`, or `{"error": "<CODE>", "message": "<sentence>"}` (show the user
the message; `INTERNAL_ERROR` retry once; `TIMEOUT` narrow and retry;
`CREDIT_LIMIT` stop and relay the message; `UNAUTHORIZED` / `FORBIDDEN` means
reconnect or lack of access). If a needed evidence call fails or returns
nothing, the corresponding asset section says the gap is open. Never
substitute a remembered figure.
## Output
Follow [references/deck-grammar.md](references/deck-grammar.md) for section
order and the evidence-table shape. The short version:
```markdown
# [Asset title] — [subject]
_Internal draft. Assembled from Zime call and CRM data on [date]. Not reviewed
by marketing or legal._
## The problem (in their words)
> "[verbatim quote]" — [name, title], [date]
## [Evidence section — signals / risks / expansion]
| [Account] | [Signal] | Evidence | Date | Next action |
|---|---|---|---|---|
| [account] | [signal] | [what was said] | [date] | [action] |
## What this means
[synthesis — clearly framing, not new facts]
## Open gaps
- [section with no supporting evidence returned]
---
_Sources: Zime call recordings — [account], [dates]._
```
Present the finished asset as plain markdown: short sections with labelled
lines, status written as words (at risk, needs attention, on track), any
commentary in the chat around it, and gaps kept visible as "not stated".
## Deliver in the right format
- **Account review deck:** this is a presentation, not a document. Break the
content above into one slide per section (title, problem, evidence, what
it means, gaps), as a markdown outline with one heading per slide, so the
user can paste it into Slides or another deck tool. Tell the user the
layout will need a quick pass in their deck tool to clean up spacing and
bullets.
- **Every other asset type** (one-pager, battlecard section, case study,
objection talking points): these are documents, not slides. Hand back the
markdown, ready to paste into Docs or another editor.
### Rules
- **Every row: account, evidence, date.** A row missing any of the three
doesn't ship — that's the format's whole discipline.
- **Quotes come from `get_transcript`**, attributed to a named speaker with a
date. No exceptions.
- **Relay claims close to the agent's phrasing.** Don't sharpen "the
integration worried them" into "integration is why we're losing".
- **Never invent a number.** No ROI figure, headcount, or percentage that a
tool didn't return. If the asset format wants an ROI section and no numbers
came back, the section says so.
- **Keep Open gaps.** Removing it makes a partial asset look complete.
- **Always caption it as an internal draft**, every time. Calls contain
confidential customer language; anything built here needs review before it
goes to a prospect, into an external deck, or anywhere published.
## Tips
1. **Name the asset type** — "account review deck" and "proof point" have
different section orders.
2. **Ask for dates in the evidence question** — retrofitting them later means
re-calling.
3. **Fetch quotes separately** — one `get_transcript` call is what makes a
quote quotable.
4. **Gaps are useful** — they tell the rep what to go ask on the next call.
## Local mode (only when no zime-mcp server is connected)
If the user provides transcripts or a CRM export, build a narrower asset from
those files only — same rule: every claim traces to a line or field in the
provided files. Open with one line saying the asset covers only those files,
not the full account history, and repeat the internal-draft caveat.
## What this sends where
MCP mode sends query words (to `list_accounts`/`list_deals`), question text
naming the subject (to `ask_zime`), and query/dates plus a `call_id`
(to `get_transcript`). Local mode reads only the provided files. At the
start, the skill calls the Zime connector tool `skill_used`, which records the
skill's id, version and name with your user and session in Zime's usage log.
## Related Skills
- **competitive-intelligence** — gather competitor evidence first
- **review-account** — the analysis behind a deal-focused asset
- **create-sales-to-cs-handover** — the handover doc, a different house format
- **review-call** — the exact quotable line from one call
Referenced files: 1 — file references are metadata, not package contents.
create-sales-to-cs-handover10.2 KB
View saved version →
---
name: create-sales-to-cs-handover
description: "Builds the Sales to CS handover doc for one deal or account. Covers stakeholders, why we won, open objections, commitments, and call history. Gives you the handover as markdown, ready to paste into a doc."
license: MIT
metadata:
zime:skill-id: 0e82dc75-cffd-449c-b45f-ba8b00f94ea1
zime:tag: workflow
zime:roles: ae,cs
zime:visibility: global
zime:skill-version: "1"
zime:marketplace-version: 0.1.20
---
# Sales → CS Handover
Before anything else, call the Zime connector tool `skill_used` with skill_id `0e82dc75-cffd-449c-b45f-ba8b00f94ea1`, skill_version `1` and skill_slug `create-sales-to-cs-handover`. It records which skill ran for Zime usage analytics. If the Zime connector is not available, skip this step and continue.
Fills the handover document CS uses to accept an account. Two kinds of field
live in it, and the difference is the whole skill:
1. **Fields Zime data can fill** — stakeholders, why we won, objections,
commitments, call history, current state.
2. **Fields only the rep knows** — NDA links, drive folders, demo slots,
client sensitivities, what not to say.
Category 2 is left as an explicit `[SALES TO FILL]` prompt. Never guessed.
## Why guessing is worse than blank here
CS accepts or rejects a handover based on this document. An invented client
sensitivity ("don't mention pricing") gets treated as real and changes how CS
talks to the customer. A blank field gets chased and filled. The template's own
rule is that CS pushes the start date rather than accepting an incomplete
handover — so a plausible-looking fabrication defeats the control the document
exists to provide.
## How It Works
```
┌─────────────────────────────────────────────────────────────────┐
│ SALES → CS HANDOVER │
├─────────────────────────────────────────────────────────────────┤
│ STEP 1 — RESOLVE │
│ ✓ list_deals (deal handover) or list_accounts (account) │
├─────────────────────────────────────────────────────────────────┤
│ STEP 2 — GATHER │
│ + ask_zime — why we won, objections, commitments │
│ + list_meetings — call history, cadence, last engagement │
├─────────────────────────────────────────────────────────────────┤
│ STEP 3 — FILL, DON'T GUESS │
│ ✓ Zime-backed fields filled with evidence + dates │
│ ! Rep-only fields left as [SALES TO FILL] │
│ ✓ Open gaps listed at the top so CS sees them first │
├─────────────────────────────────────────────────────────────────┤
│ STEP 4 — DELIVER │
│ ✓ Hand back the filled handover as markdown, ready to paste │
├─────────────────────────────────────────────────────────────────┤
│ LOCAL FALLBACK (no zime-mcp) │
│ ~ Narrower draft from provided transcripts or CRM export │
└─────────────────────────────────────────────────────────────────┘
```
## Usage
```
@create-sales-to-cs-handover <deal or account name>
```
In the ChatGPT desktop app you can also type `/create-sales-to-cs-handover`.
Build the handover for the deal or account the user named.
## Routing
- Deal strategy while still selling, or the account's CRM record alone →
`review-account`.
- Just the open commitments → `actions-commitments`.
- An account review deck for a QBR → `create-sales-asset`.
## What I Need From You
The deal or account name. Also useful, and otherwise left blank:
- Who's handing over, and to whom
- Anything sensitive CS must not say or do
- Links (drive folder, NDA, charter) if you have them
Anything not supplied comes back as a `[SALES TO FILL]` prompt — that's the
design, not a shortfall.
## MCP mode (required when zime-mcp is connected)
**Required tools:** `list_deals` / `list_accounts` (resolve), `ask_zime`
(evidence), `list_meetings` (call history).
### Step 1 — resolve
```json
{ "query": "Acme" }
```
`multiple_matches` → show candidates, ask, pin. A handover written about the
wrong account is worse than none.
### Step 2 — gather, asking for dates and names
Name the deal or account in the question itself, since `ask_zime` has no
separate deal/account scoping argument:
```json
{ "question": "For the Acme deal: who are the stakeholders and what does each one care about, why did we win, what objections or blockers are still live, and what did we commit to delivering? Give the evidence, the speaker, and the date for each." }
```
Call history:
```json
{ "query": "Acme", "start_date": "2026-02-01", "end_date": "2026-08-13" }
```
Ask for speaker and date explicitly — a stakeholder motivation with no source
can't be validated by CS.
### Outcomes
Usual shapes — `resolved` / `multiple_matches` / `no_match`, or
`{"error": "<CODE>", "message": "<sentence>"}` (show the user the message;
`INTERNAL_ERROR` retry once; `TIMEOUT` narrow and retry; `CREDIT_LIMIT` stop
and relay the message; `UNAUTHORIZED` / `FORBIDDEN` means reconnect or lack
of access). A failed or empty evidence call means that section becomes a
`[SALES TO FILL]` prompt — it does not become a guess.
## Output
Follow [references/handover-template.md](references/handover-template.md) for
the full field list. Structure:
```markdown
# Sales → CS Handover: [Account]
_Drafted from Zime call and CRM data on [date]. Sections marked
[SALES TO FILL] need the rep before CS can accept._
## Open gaps — blocking acceptance
- [ ] [field] — [SALES TO FILL]
## 1. Deal and commercial status
| Field | Value | Source |
|---|---|---|
| Deal | [name] · [stage] · [amount] | CRM |
| Close date | [date] | CRM |
| NDA / charter links | [SALES TO FILL] | — |
## 2. Client context
[what they do, team shape, tooling — evidence + date, or SALES TO FILL]
## 3. Stakeholders
| Name | Title | Role | What they care about | Source |
|---|---|---|---|---|
| [name] | [title] | [champion / DM / economic buyer] | [motivation] | [call, date] |
## 4. Why we won
- **[hook]** — [evidence] — [speaker, date]
## 5. Objections and blockers still live
| Objection | Raised by | Date | Status |
|---|---|---|---|
## 6. Commitments made
| Commitment | Owner | Due | Source |
|---|---|---|---|
## 7. Call history
| Date | Meeting | Type | Attendees |
|---|---|---|---|
**Last engagement:** [date] · **Cadence:** [observed pattern]
## 8. Marching orders for CS
[first actions, from what the calls indicate]
## 9. What NOT to do — client sensitivities
[SALES TO FILL] — not inferable from call data
## 10. Open questions for CS to chase
- [unresolved item] — [source]
```
Present the finished handover as plain markdown: short sections with labelled
lines, status written as words (at risk, needs attention, on track), any
commentary in the chat around it, and gaps kept visible as "not stated" or
`[SALES TO FILL]`.
## Deliver
Hand back the filled-in markdown above as the finished handover, ready for
the user to paste into Docs or another editor and share with CS. Say plainly
that the paste is a manual step, so the user knows it's needed.
### Rules
- **`[SALES TO FILL]` is mandatory** for: NDA and charter links, drive folder,
demo/kickoff slots, client sensitivities, what-not-to-say, post-POC
commercial terms. Never infer these — none are reliably in call data.
- **Every Zime-filled row carries a source** (call + date). CS validates the
handover; unsourced claims can't be validated.
- **Lead with Open gaps.** CS reads that first and knows immediately whether
this handover is acceptable.
- **A stakeholder needs a real source.** No inferring a champion from who
talked most.
- **Never invent an owner or a due date** on a commitment. "not stated" is
correct.
- If the account has almost no call history, say so plainly at the top — a
thin handover honestly labelled is useful; a padded one is not.
## Tips
1. **Supply the links up front** — they're the most common blockers to
acceptance.
2. **Sensitivities are yours to write** — the calls rarely contain them and
guessing them is the most dangerous fabrication in this document.
3. **Widen the call-history window** — handovers want the whole relationship,
not the last 90 days.
4. **Chase the gaps with `actions-commitments`** before handing over.
## Local mode (only when no zime-mcp server is connected)
If the user provides transcripts or a CRM export, draft from those files only.
Open with one line saying the draft covers only the provided files, so
stakeholder motivations and objections from other calls are missing by
construction. Expand `[SALES TO FILL]` to cover everything the files don't
carry.
## What this sends where
MCP mode sends query words (to `list_deals`/`list_accounts`), the evidence
question naming the deal or account (to `ask_zime`), and query words
plus dates (to `list_meetings`). Local mode reads only the provided files.
At the start, the skill calls the Zime connector tool `skill_used`, which
records the skill's id, version and name with your user and session in
Zime's usage log.
## Related Skills
- **actions-commitments** — close the gaps before handing over
- **review-account** — the pre-handover view of the same deal
- **create-sales-asset** — the account review deck CS will run later
Referenced files: 1 — file references are metadata, not package contents.
daily-briefing7.37 KB
View saved version →
---
name: daily-briefing
description: "Gives you your day at a glance. Today's meetings, what changed on your deals, and what needs attention now."
license: MIT
metadata:
zime:skill-id: aa4d7a1f-2f3c-4c5d-be5f-6d7cec6f6816
zime:tag: workflow
zime:roles: ae,bdr
zime:visibility: global
zime:skill-version: "1"
zime:marketplace-version: 0.1.20
---
# Daily Briefing
Before anything else, call the Zime connector tool `skill_used` with skill_id `aa4d7a1f-2f3c-4c5d-be5f-6d7cec6f6816`, skill_version `1` and skill_slug `daily-briefing`. It records which skill ran for Zime usage analytics. If the Zime connector is not available, skip this step and continue.
Answers "what do I need to know this morning?" — the day's meetings, what
moved on the deals, and what's about to slip. It's the skill a rep runs
before their first call, so the briefing stays short.
## How It Works
```
┌─────────────────────────────────────────────────────────────────┐
│ DAILY BRIEFING │
├─────────────────────────────────────────────────────────────────┤
│ NO ENTITY RESOLVE │
│ ✓ Scope is the rep's whole day — nothing to pin │
├─────────────────────────────────────────────────────────────────┤
│ OPTIONAL — CONCRETE SCHEDULE │
│ ✓ list_meetings for today's actual meetings, with times │
├─────────────────────────────────────────────────────────────────┤
│ DELEGATE (Zime agent) │
│ + ask_zime for what changed and what needs attention │
│ + Kept short — this runs before the first call │
├─────────────────────────────────────────────────────────────────┤
│ LOCAL FALLBACK (no zime-mcp) │
│ ~ Read a calendar or CRM export the user provides │
└─────────────────────────────────────────────────────────────────┘
```
## Usage
```
@daily-briefing [today | this week | date]
```
In the ChatGPT desktop app you can also type `/daily-briefing`.
Brief the user for the day or window they asked for, defaulting to today.
## Routing
- Prep for ONE specific upcoming call → `call-prep`. This skill lists the
day; that one prepares you for a meeting.
- Full pipeline health across many deals, or one deal in depth →
`review-account`.
- Everything outstanding regardless of today → `actions-commitments`.
## What I Need From You
Nothing. Default to today. Accept "this week" or a specific date if given.
## MCP mode (required when zime-mcp is connected)
**Required tool:** `ask_zime`. **Recommended:** `list_meetings` for the
schedule.
Assembling the briefing from memory or from deals mentioned earlier in the
chat is a failure of this skill — the point is what changed since the rep last
looked, which by definition isn't in the conversation.
### Step 1 (optional) — the actual schedule
For a concrete list of today's meetings with times, call `list_meetings` with
today's date on both ends:
```json
{ "query": "", "start_date": "2026-08-13", "end_date": "2026-08-13" }
```
This returns both scheduled meetings and recorded calls for the day. Use it
when the rep wants times and attendees; skip it if they only asked what
changed.
### Step 2 — delegate the briefing
```json
{ "question": "Brief me for today: what meetings do I have, what changed on my deals since yesterday, and what needs my attention today. Include the specific deal or account behind each item." }
```
`ask_zime` has no memory of this conversation and no date parameters — put the
day in the question text. Ask for the deal or account behind each item, or you
get a list of alerts with nothing to act on.
### Outcomes
- **A briefing** — deliver per Output below.
- **A quiet day** — "nothing changed and you have no meetings" is a valid,
useful answer. Don't manufacture items to fill it out.
- **An error** — `{"error": "<CODE>", "message": "<sentence>"}`. Show the
user the message. `INTERNAL_ERROR` retry once; `TIMEOUT` narrow the window
and retry; `CREDIT_LIMIT` stop and relay the message; `UNAUTHORIZED` /
`FORBIDDEN` means reconnect or lack of access. If it fails twice, say so
and offer the local fallback. If only `list_meetings` succeeded, deliver
the schedule alone and say the change summary was unavailable — a partial
briefing labelled as partial is fine.
## Output
Schedule first (a rep reads this between calls), then what changed.
```markdown
**Briefing — [date]**
### Today's meetings
| Time | Meeting | Account | Prep |
|---|---|---|---|
| [time] | [title] | [account] | [prepped / not prepped] |
### What changed
[the agent's returned summary, relayed as-is]
### Needs attention today
[the agent's returned items, relayed as-is]
_Live calendar, CRM, and call data via Zime._
```
Rules:
- Relay the agent's sections **as-is** — don't re-prioritize what needs
attention. Ordering is judgment, and reordering it silently overrides that.
- Keep the account or deal name on every item. An alert without an entity
isn't actionable.
- Keep times exactly as returned, and say which timezone if the tool states
one. A briefing with a shifted time is worse than no briefing.
- If a section came back empty, show it empty. A short honest briefing beats a
padded one.
- Don't fold in items from earlier in the conversation.
## Tips
1. **Run it before your first call** — that's the design point.
2. **"This week" works** — say so in the request and it goes into the question.
3. **Not prepped?** Chain into `call-prep` for the meeting that matters most.
4. **Wanting depth, not speed?** That's `review-account`.
## Local mode (only when no zime-mcp server is connected)
If the user provides a calendar or CRM export, list the day's meetings and
flag deals with past-due close dates or missing next steps from that file.
Open with one line saying the briefing covers only the provided file — so
"what changed" isn't available, since a static export has no change history.
Don't infer change from a snapshot.
## What this sends where
MCP mode sends a date range and empty query (to `list_meetings`) and the
question text (to `ask_zime`). Local mode reads only the provided file.
At the start, the skill calls the Zime connector tool `skill_used`, which
records the skill's id, version and name with your user and session in
Zime's usage log.
## Related Skills
- **call-prep** — prepare for the meeting this briefing surfaced
- **review-account** — the deeper pipeline or single-deal view
- **actions-commitments** — everything open, not just today
follow-up8.26 KB
View saved version →
---
name: follow-up
description: "Drafts the follow-up email after one call. Recaps what was agreed and states the next step, using only what was actually said. Always a draft for you to review before sending."
license: MIT
metadata:
zime:skill-id: 92e9d1f2-67c9-43c2-9d25-26e6cefe69d0
zime:tag: communication
zime:roles: ae,bdr
zime:visibility: global
zime:skill-version: "1"
zime:marketplace-version: 0.1.20
---
# Follow-up
Before anything else, call the Zime connector tool `skill_used` with skill_id `92e9d1f2-67c9-43c2-9d25-26e6cefe69d0`, skill_version `1` and skill_slug `follow-up`. It records which skill ran for Zime usage analytics. If the Zime connector is not available, skip this step and continue.
Turns "draft a follow-up for my Acme call" into a sendable email. The Zime
call agent drafts it from what was actually said and committed, so the recap
lines and next steps are real rather than plausible.
## How It Works
```
┌─────────────────────────────────────────────────────────────────┐
│ FOLLOW-UP │
├─────────────────────────────────────────────────────────────────┤
│ STEP 1 — RESOLVE (this skill) │
│ ✓ list_meetings, recorded calls only │
│ ✓ Ambiguous → show candidates, ask, pin call_id │
├─────────────────────────────────────────────────────────────────┤
│ STEP 2 — DELEGATE (Zime agent) │
│ + ask_zime drafts from real commitments and next steps, naming the call │
│ + Returns the draft; this skill formats and captions it │
├─────────────────────────────────────────────────────────────────┤
│ ALWAYS │
│ ! Delivered as a DRAFT — the rep sends it, not this skill │
├─────────────────────────────────────────────────────────────────┤
│ LOCAL FALLBACK (no zime-mcp) │
│ ~ Draft from a transcript file the user provides │
└─────────────────────────────────────────────────────────────────┘
```
## Usage
```
@follow-up <company or call> [+ when]
```
In the ChatGPT desktop app you can also type `/follow-up`.
Draft the follow-up for the call the user named.
## Routing
- A structured internal summary rather than a customer email → `review-call`.
- Just the open items and owners → `actions-commitments`.
- Prep for the NEXT call → `call-prep`.
## What I Need From You
Which call. If the user wants a particular emphasis ("keep it short", "push
for the pilot", "address the pricing concern"), say so — that shapes the
draft. Only recorded calls can be drafted from.
## MCP mode (required when zime-mcp is connected)
**Required tools:** `list_meetings` (resolve) and `ask_zime` (draft).
> `ask_zime` routes to Zime's global agent, with no separate `call_id`
> argument — name the call (title and date) in the question text. Writing
> the email yourself while it's available is a failure of this skill: the
> agent knows which commitments were actually made, and an invented promise
> in a customer-facing email is the most expensive mistake this skill can
> make.
### Step 1 — resolve the call
```json
{ "query": "Acme", "start_date": "2026-08-06", "end_date": "2026-08-13", "recorded": true }
```
`multiple_matches` → show candidates with dates, ask, pin. `no_match` → say
the window likely excludes it or it wasn't recorded; offer to widen. Never
draft from a different call.
### Step 2 — delegate the draft
```json
{ "question": "Draft a follow-up email to the customer for the Acme call on Aug 12: recap what was discussed, restate the commitments we made, and propose the agreed next step with timing." }
```
Add the user's emphasis to the question verbatim if they gave one. Resolve
pronouns to real names — the agent has no memory of this conversation.
### Outcomes
- **A draft** — deliver per Output below.
- **The agent has nothing** (e.g. no commitments detected) — say so and don't
manufacture next steps to fill the email.
- **An error** — `{"error": "<CODE>", "message": "<sentence>"}`. Show the
user the message. `INTERNAL_ERROR` retry once; `TIMEOUT` retry once;
`CREDIT_LIMIT` stop and relay the message; `UNAUTHORIZED` / `FORBIDDEN`
means reconnect or lack of access. If it fails twice, say plainly the
drafting service couldn't be reached and offer the local fallback — never
pass a hand-written email off as agent-backed.
## Output
Two parts: a one-line provenance caption, then the email in plain text.
```markdown
**Draft follow-up — [call title]** · [date] · to [recipients]
_Review before sending. Every commitment below came from the call itself._
---
Subject: [subject line]
Hi [name],
[recap of what was discussed]
[commitments made, restated plainly]
[the agreed next step, with timing]
Best,
[rep name]
```
### Email style rules
The body is going into an email client, so:
1. **No markdown formatting.** No asterisks, no bold, no headers. Plain text
that reads naturally anywhere.
2. **Short paragraphs**, blank line between sections.
3. **Plain dashes** for lists, not bullets or fancy formatting.
4. **Concise but complete** — customers are busy; don't pad.
**Good:**
```
Here's what we agreed:
- Quote for 20 seats by Friday
- Security review doc from your side
- Follow-up call the week of the 25th
```
**Bad:**
```
**What We Agreed:**
- **Quote** for 20 seats by Friday
```
### Grounding rules
- Every commitment, number, date, and name in the draft must have come from
the agent's output. If the agent didn't return it, it doesn't go in the
email — a plausible-sounding promise to a customer is worse than an
incomplete draft.
- If a needed piece is missing (e.g. no date was agreed), leave a visible
`[confirm timing]` placeholder rather than inventing one.
- Never state a discount, price, or contractual term the call didn't contain.
- Always caption it as a draft. This skill does not send email.
### Render it inline in the chat
Deliver the caption and the email **inline in the chat response**, as plain
text. The rep is going to select the email body and paste it into a mail
client, so keep it in the chat rather than in a separate document or panel.
The email style rules above still govern the body — plain text, no markdown,
plain dashes for lists. Keep any `[confirm timing]` placeholders visible
rather than tidying them away.
## Tips
1. **Say the emphasis you want** — "short and push for the pilot" changes the
draft meaningfully.
2. **Placeholders are a feature** — `[confirm timing]` beats a made-up date.
3. **Read before you send** — the draft is grounded, not proofread for tone
against your relationship with this customer.
## Local mode (only when no zime-mcp server is connected)
If the user provides a transcript, draft from that file only, with the same
grounding rules and the same draft caption. Open with one line saying the
draft covers only the provided transcript.
## What this sends where
MCP mode sends the query words and date range (to `list_meetings`), then the
drafting question naming the call (to `ask_zime`). Local mode reads
only the provided file. Neither mode sends email. At the start, the skill
calls the Zime connector tool `skill_used`, which records the skill's id,
version and name with your user and session in Zime's usage log.
## Related Skills
- **review-call** — the internal summary version
- **actions-commitments** — what's still open across calls
review-account16.4 KB
View saved version →
---
name: review-account
description: "Everything about the commercial side: one account, one deal, or the whole pipeline, as a CRM record or as a grounded analysis. Use for \"pull up the Acme account\", \"what stage is the Acme expansion\", \"who owns this deal\", \"how do I win the Acme deal\", \"why is this deal at risk\", \"what's at risk this quarter\", \"what's stalled\", \"review Priya's pipeline\", or \"what should I focus on this week\". Works out scope (account, deal, or portfolio) and depth (facts or judgment) from the question itself. Grounded in the live CRM and the calls behind it, never generic sales advice, and reports a dimension as unknown rather than filling it with best practice. For a company not yet in CRM, use account-research instead."
license: MIT
metadata:
zime:skill-id: 8b888fca-2a7d-442c-988d-fdb64dce6155
zime:tag: intelligence
zime:roles: ae,se,cs,pm
zime:visibility: global
zime:skill-version: "1"
zime:marketplace-version: 0.1.20
---
# Review Account
Before anything else, call the Zime connector tool `skill_used` with skill_id `8b888fca-2a7d-442c-988d-fdb64dce6155`, skill_version `1` and skill_slug `review-account`. It records which skill ran for Zime usage analytics. If the Zime connector is not available, skip this step and continue.
Everything about the commercial side: one account, one deal, or the whole
pipeline, as a record or as a grounded analysis. Two questions decide the
route, and this skill answers both from the question itself rather than making
the user pick a tool.
## The two questions
**Scope** — how many things is this about?
| Signal | Scope |
| ---------------------------------------------------------------- | --------- |
| One company named, asked about the company itself | Account |
| One deal or opportunity named | Deal |
| No entity named, or a filter like a rep, segment, stage, quarter | Portfolio |
**Depth** — facts, or judgment?
| Signal | Depth |
| ------------------------------------------------------- | -------- |
| stage, amount, owner, close date, domain, industry | Record |
| why, risk, what should I do, what's stuck, how do I win | Analysis |
Portfolio scope is always Analysis: there is no single record to return.
## The line this skill holds
Generic sales advice is the failure mode on every Analysis route.
"Multi-thread the account" and "create urgency" are true of every deal and
therefore useless about this one. If the agent returns nothing on a dimension,
say the dimension is unknown rather than filling it with best-practice filler.
Unknown is information: no objections surfaced often means discovery was thin,
not that the deal is clean.
## How It Works
```
┌─────────────────────────────────────────────────────────────────┐
│ REVIEW ACCOUNT │
├─────────────────────────────────────────────────────────────────┤
│ PORTFOLIO (many deals — no entity named) │
│ ✗ Do NOT resolve one deal first; that answers a smaller │
│ question than the one asked │
│ + ask_zime, with window/segment/rep stated in the question │
├─────────────────────────────────────────────────────────────────┤
│ DEAL (one opportunity named) │
│ ✓ list_deals → one deal_id │
│ ▸ Record → stop, return the fields │
│ ▸ Analysis → ask_zime, naming the deal in the question │
├─────────────────────────────────────────────────────────────────┤
│ ACCOUNT (one company named, in CRM) │
│ ✓ list_accounts → one account_id │
│ ▸ Record → stop, return the fields │
│ ▸ Analysis → ask_zime, naming the account │
├─────────────────────────────────────────────────────────────────┤
│ NOT THIS SKILL (route away) │
│ ✗ Company NOT in CRM yet → account-research │
│ ✗ Open commitments and owners → actions-commitments │
│ ✗ Competitor patterns → competitive-intelligence │
│ ✗ Today's schedule → daily-briefing │
│ ✗ One call's recap or words → review-call │
├─────────────────────────────────────────────────────────────────┤
│ LOCAL FALLBACK (no zime-mcp) │
│ ~ Analyze a CRM export the user provides │
└─────────────────────────────────────────────────────────────────┘
```
## Usage
```
@review-account <account, deal, segment, rep, or window> [+ your angle]
```
In the ChatGPT desktop app you can also type `/review-account`.
Review the account, deal or pipeline scope the user named, with any angle
they gave.
## Routing
- A **prospect** not yet in CRM, ICP fit, outside company intel →
`account-research`. That skill web-searches; this one reads CRM and calls.
- Open commitments and who owes what → `actions-commitments`.
- Competitor patterns across deals → `competitive-intelligence`.
- Today's schedule and immediate priorities → `daily-briefing`.
- One call's recap, record, or exact words → `review-call`.
- Preparing for a specific upcoming call → `call-prep`.
## What I Need From You
Nothing required for a portfolio review. For one deal or account, the name.
Scope narrows a portfolio review usefully: a rep, a segment, a close-date
window, or a stage.
If the user has an angle ("they went quiet", "pricing is the blocker", "I only
care about what can close this month"), pass it through verbatim. It focuses
the agent's analysis and changes what it prioritizes.
## MCP mode (required when zime-mcp is connected)
**Required tools:** `list_accounts`, `list_deals`, `ask_zime`.
Computing pipeline totals, risk calls, or "what's stuck" from memory or from
deals mentioned earlier in the chat is a failure of this skill. Those numbers
have to come from the live CRM, and a remembered figure in a pipeline review
gets repeated in a forecast. A remembered stage or amount can be stale or
wrong.
### Portfolio — `ask_zime` only
`ask_zime` takes a single `question`. It has no memory of this conversation and
no separate filter or date parameters, so **everything belongs in the question
text**: the window, the segment, the rep, the stage.
```json
{ "question": "Which deals in the current quarter are most at risk, and why? Include stage, amount, close date, owner, and the specific evidence behind each risk call." }
```
Scoped to a rep and a lens:
```json
{ "question": "Review Priya's pipeline for deals closing this month: which are most likely to close, which are stalled, and what is the single next action on each?" }
```
Ask for the evidence explicitly. A risk call without a reason is not
reviewable, and the agent will supply the reasoning if the question asks for
it.
> This is the broadest question any skill asks, so it is the slowest. If it
> takes a while, that's the agent reading across many deals rather than a
> failure.
### Deal — `list_deals`, then optionally `ask_zime`
Arguments for `list_deals`:
- `query` — deal or account name, e.g. "Acme expansion". Omit if you already
have `deal_id`.
- `deal_id` — pin an exact deal from a prior `multiple_matches` response or
already known this conversation. Never invent one.
- `account_name` — narrow when the deal name alone is ambiguous.
- `start_date` / `end_date` — YYYY-MM-DD. Deals are **not** date-scoped by
default, and a deal that closed two years ago is still a legitimate subject.
Only pass dates if the user bounded it; a stray range can hide the deal
entirely.
For Analysis, follow with `ask_zime`, naming the deal in the question text
since there is no `deal_id` argument:
```json
{ "question": "For the Acme expansion deal: where does it actually stand? Cover the objections and risks in play, the stakeholders and who is championing us, what has moved and what has stalled, and the two or three concrete moves that would most advance it." }
```
If the user gave an angle, append it verbatim: *"The rep says they've gone
quiet since the security review, factor that in."* Resolve pronouns to real
names; the agent has no memory of this conversation.
### Account — `list_accounts`, then optionally `ask_zime`
Arguments for `list_accounts`:
- `query` — account or company name, e.g. "Acme". Omit if you already have
`account_id`.
- `account_id` — pin an exact account. Never invent one.
- `domain` — narrow when the name alone is ambiguous. A domain resolves more
precisely than a name.
### Outcomes, for every resolve step
- `{"status": "resolved", "data": {...}}` — deliver per Output, or continue to
`ask_zime` if the depth is Analysis.
- `{"status": "multiple_matches", "candidates": [...]}` — show candidates with
enough detail to tell them apart (stage and amount for deals, domain for
accounts), ask which one, re-call pinned. Never guess. "The most recent one"
→ take the first.
- `{"status": "no_match", "candidates": [...]}` — nothing matched confidently.
This does **not** mean it doesn't exist: it may be named differently in CRM,
outside the date window, or not visible to this user. Say that, show
near-misses, and consider whether the user meant a prospect (→
`account-research`). Never substitute a similarly-named account or deal, and
never tell the user the deal doesn't exist.
- An error — `{"error": "<CODE>", "message": "<sentence>"}`. Show the user
the message. `INTERNAL_ERROR` is usually transient, retry once. `TIMEOUT`
means narrow the scope or window and retry. `CREDIT_LIMIT` means stop and
relay the message. `UNAUTHORIZED` / `FORBIDDEN` means reconnect or lack of
access. `INVALID_ARGUMENT` means malformed arguments, fix and re-call. If it
fails twice, say plainly the service couldn't be reached and offer the local
fallback. Never pass generic advice off as a grounded read, and never
substitute remembered numbers.
## Output
### Account record
```markdown
**[Account name]**
| Field | Value |
|---|---|
| Domain | [domain] |
| Industry | [industry] |
| Account type | [type] |
| Owner | [owner name / email] |
| Account ID | `[crm_id]` |
_Live CRM record via Zime._
```
### Deal record
```markdown
**[Deal name]** · [Account name]
| Field | Value |
|---|---|
| Stage | [stage] |
| Amount | [amount] |
| Owner | [owner name / email] |
| Close date | [date] |
| Pipeline | [pipeline] |
| Deal ID | `[crm_deal_id]` |
_Live CRM record via Zime._
```
For both records: relay fields exactly as returned, with no inference and no
rounding. A field the record doesn't carry is shown as absent, never filled
with a plausible guess. Keep the ID line; later skills pin to it.
### Analysis, any scope
The agent's analysis **is** the deliverable. This skill adds the envelope so
the reader knows what was analyzed and, for a deal, its hard facts:
```markdown
**Deal strategy — [deal name]** · [account]
**Stage:** [stage] · **Amount:** [amount] · **Close:** [close date] · **Owner:** [owner]
[the agent's returned analysis, relayed as-is]
_Grounded in this deal's calls and CRM record via Zime._
```
For a portfolio review, name the scope instead, so the numbers are never read
against the wrong window:
```markdown
**Pipeline review** · [window] · [segment or rep, if scoped]
[the agent's returned analysis, relayed as-is]
_Live CRM and call data via Zime._
```
Rules:
- Relay the analysis **as-is**. Don't re-rank the risks or deals, re-bucket
them, merge the moves, or recompute a total to "check" it. A number you
derive and a number the agent returned look identical on the page but are not
equally grounded. The ordering is part of the judgment.
- Keep amounts, stages, close dates and owners exactly as returned. Don't round
$47,300 to $47K.
- Keep evidence and dates where the agent attached them. "Raised on the Jun 18
call" and "stalled, no customer reply since Jul 2" are what make a risk
actionable rather than an assertion.
- Don't append your own recommendations. If the agent surfaced two moves,
deliver two; a third from general knowledge would be indistinguishable in
presentation but not grounded.
- Don't add deals from memory or from earlier in the chat, even if they seem
obviously relevant. The agent's scope is the scope.
- Where a dimension came back empty, state it as unknown.
- If the user asked for a specific window and the answer doesn't state one, say
the window is unconfirmed rather than assuming it matched.
### Present an analysis in markdown
Present a finished analysis as plain markdown, so it is scannable at a
glance:
- **Short sections with labelled lines** for each block, not one long wall
of text.
- **Status written as words** — at risk, needs attention, on track — beside
the field it describes.
- **Keep prose in the chat response, around the structured result.**
Caveats, what you did, and what to do next belong in the surrounding
message.
- Every grounding rule above still applies. A missing value stays visible
as "not stated" rather than being quietly dropped to keep a section tidy.
A plain record needs nothing extra; the table is already the answer.
## Tips
1. **Domain beats name** for accounts — "acme.com" resolves more precisely
than "Acme".
2. **Name the account if the deal name is generic** — "the renewal" matches
many; "the Acme renewal" resolves.
3. **State the window** on a portfolio review; there are no date parameters, so
"this quarter" belongs in the question.
4. **Ask for the why**, or you get labels without reasons.
5. **Give your angle** — "they've gone quiet" or "only what can close this
month" produces a sharper read than an open-ended ask.
6. **CRM vs prospect** — researching someone you've never sold to is
`account-research`, not this.
7. **Expect portfolio reviews to be slower** than single-entity questions;
they read far more.
## Local mode (only when no zime-mcp server is connected)
If the user provides a CRM export (`.csv`), work from that file and open with
one line saying the answer is limited to it, so call activity, stage movement
and anything not in the export are missing by construction. For a portfolio
review, flag stalled deals, past-due close dates, missing next steps and
single-threaded deals, ranked by amount and close date. Don't infer engagement
from a CSV that has no activity columns. For one deal or account, trace every
claim to a line or field in the file. Mark gaps as gaps rather than filling
them with standard playbook advice. No file and no connection → say so rather
than guessing at stage, amount, or close date.
## What this sends where
MCP mode sends the query words, domain, dates and any pinned id to
`list_accounts` or `list_deals`, and the analysis question to `ask_zime`, which
reads the CRM and call data the workspace already holds. Local mode reads only
the file the user provided. At the start, the skill calls the Zime connector
tool `skill_used`, which records the skill's id, version and name with your
user and session in Zime's usage log.
## Related Skills
- **account-research** — a company not yet in CRM, web research and ICP fit
- **actions-commitments** — what's still open, and who owes it
- **review-call** — one call's record, recap, or exact words
- **create-sales-asset** — build collateral from this deal's evidence
- **create-sales-to-cs-handover** — package a won account for CS
review-call13.3 KB
View saved version →
---
name: review-call
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."
license: MIT
metadata:
zime:skill-id: af945a16-edc8-4838-ac82-6b315a89527d
zime:tag: intelligence
zime:roles: ae,se,cs
zime:visibility: global
zime:skill-version: "1"
zime:marketplace-version: 0.1.20
---
# 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`. It records which skill ran for Zime usage analytics. If the Zime connector is not available, skip this step and continue.
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 <company, topic, or attendee> [+ when] [+ what you want]
```
In the ChatGPT desktop app you can also type `/review-call`.
Review the call the user named, at the depth they asked for.
## 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": "<CODE>", "message": "<sentence>"}`. Show the user
the message. `INTERNAL_ERROR` retry once; `TIMEOUT` narrow the window and
retry; `CREDIT_LIMIT` stop and relay the message; `UNAUTHORIZED` /
`FORBIDDEN` means reconnect 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 the short labelled markdown lines
in the templates above, 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. A long transcript is easier to read and copy
as plain text.
## 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. At the
start, the skill calls the Zime connector tool `skill_used`, which records
the skill's id, version and name with your user and session in Zime's usage
log.
## 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
skill-builder11.9 KB
View saved version →
---
name: skill-builder
description: "Builds a new skill from a plain-language request, or tightens an existing one. Knows the Zime connector inside out, so a skill for calls, deals, accounts, pipeline or prep uses the right Zime tools and follows the same shape as every other Zime skill. Works for any other connector too, from a short profile of its tools. Use for \"make me a skill that…\", \"create a skill for…\", \"turn this prompt into a skill\", \"build a skill on top of Zime\", \"write a skill for another connector\", \"improve this skill\", or \"why isn't my skill triggering\". Not for running a skill: to prep a call, recap one, or review a deal, use those skills directly."
license: MIT
metadata:
zime:skill-id: ca80a662-d53f-4b06-b391-c8e62151ce8f
zime:tag: workflow
zime:roles: ae,se,bdr,marketing,pm,cs
zime:visibility: global
zime:skill-version: "2"
zime:marketplace-version: 0.1.20
---
# Skill Builder
Before anything else, call the Zime connector tool `skill_used` with skill_id `ca80a662-d53f-4b06-b391-c8e62151ce8f`, skill_version `2` and skill_slug `skill-builder`. It records which skill ran for Zime usage analytics. If the Zime connector is not available, skip this step and continue.
Turns "I wish my assistant did X for me every time" into a skill your whole
team can use. You describe the job; this skill interviews you for the parts
that matter, picks the connector tools that do the work, writes the skill in
the house shape, checks it against the rules that get skills rejected, and
hands back a folder ready to publish.
Zime ships as the built-in connector profile, so anything about calls, deals,
accounts, pipeline or call prep comes out already wired to `ask_zime`,
`list_meetings`, `get_transcript`, `list_deals`, `list_accounts`,
`get_contact` and `prep_note`. Any other connector works from a profile you
fill in once, or from its live tool list if it is connected in this chat.
## How It Works
```
┌─────────────────────────────────────────────────────────────────┐
│ SKILL BUILDER │
├─────────────────────────────────────────────────────────────────┤
│ 1 INTERVIEW one job, trigger phrases, output shape, scope │
│ 2 PROFILE Zime built in · another connector from profile │
│ · or read the connected tools right now │
│ 3 MAP which tool resolves the thing, which tool │
│ answers; one entity or many │
│ 4 DRAFT fill references/skill-template.md, every section │
│ 5 CHECK references/checklist.md — limits, links, shape │
│ 6 PACKAGE <slug>/SKILL.md (+ references/), ready to publish│
├─────────────────────────────────────────────────────────────────┤
│ NOT THIS SKILL (route away) │
│ ✗ Actually prepping, recapping, reviewing → that skill │
│ ✗ A one-off answer with no reuse → just ask Zime │
└─────────────────────────────────────────────────────────────────┘
```
## Usage
```
@skill-builder <what the skill should do> [for <connector>]
```
In the ChatGPT desktop app you can also type `/skill-builder`.
Build a skill that does what the user described.
## Routing
- You want the answer once, not a reusable skill → ask the connector directly.
- You want to run an existing Zime skill → use it: `review-call`,
`review-account`, `call-prep`, `follow-up`, `actions-commitments`,
`daily-briefing`, `competitive-intelligence`, `account-research`,
`create-sales-asset`, `create-sales-to-cs-handover`.
- You have a finished skill and only want to test how well it triggers → the
description step below is the part to run; skip the rest.
## What I Need From You
Say what the skill should do in one or two sentences. I will ask for the rest,
but if you already know it, give it up front:
- **Three prompts** a colleague would type that should trigger it, and one
that should not.
- **Scope:** one call, one deal, one account, or many at once.
- **Output:** a record, a summary, an analysis, a draft to send, a file.
- **Who it is for:** AE, SE, BDR, marketing, PM, CS. Pick any.
- **Connector:** Zime unless you say otherwise.
## Step 1 — Interview
Ask only for what is missing from the list above. Then restate the skill in
one line, the way its description will read, and get a yes before drafting.
A skill that does two jobs is two skills. If the request has an "and" in it
that joins two different outputs, say so and offer to build the first one.
## Step 2 — Pick the connector profile
- **Zime:** read `references/connector-zime.md`. It lists every tool, its
arguments, what it returns, which ones cost credits, and the house rules the
ten existing Zime skills follow. Use it as written.
- **Another connector with a profile:** the user gives you a filled-in copy of
`references/connector-profile-template.md`. Use that.
- **Another connector, no profile, connected in this chat:** list its tools
from their descriptions and fill the template yourself before drafting.
Show the user the filled profile and confirm the tool names. A skill that
calls a tool by the wrong name fails silently in someone else's session.
- **No connector at all:** the skill can still be built around files the user
provides. Say plainly that it will only ever run in local mode.
## Step 3 — Map the job to tools
Every connector skill has the same two beats:
1. **Resolve.** Which tool turns the user's words into one specific record:
a `call_id`, `deal_id`, `account_id`, `meeting_id`, `contact_id`. If the
scope is many records at once, there is no resolve step; say so in the
skill and go straight to the answering tool.
2. **Answer.** Which tool produces the deliverable: a record (return its
fields), a verbatim artefact (return it untouched), or an agent's analysis
(relay it as-is).
Write down the mapping before drafting. If a step has no tool, the skill's
local mode is the only mode and the draft must say so.
## Step 4 — Draft
Open `references/skill-template.md` and fill every section in order. Do not
skip a section because it feels thin; a thin section is a signal the job is
underspecified, so go back to Step 1. The sections that people most often get
wrong:
- **Outcomes.** One line per status the tool can return, including
`multiple_matches`, `no_match` and each error code. "Never guess between
candidates" and "never substitute a similar record" belong here.
- **The grounding rule.** Say what it means to answer without the tool while
the tool is available, and name it as a failure of the skill. Copy the
wording style from the profile.
- **Output envelope.** The skill adds a header and footer around what the
tool returned; it does not rewrite, re-rank or round anything.
- **Local mode.** What the skill does with a file the user provides when the
connector is not connected, and the one-line caveat it opens with.
- **What this sends where.** Exactly which fields go to which tool. Users
read this; write it for them.
## Step 5 — Write the description last
The description is the only thing the assistant reads when deciding whether to
run the skill, so it does more work than the whole body.
- Under 1,024 characters. The Zime dashboard allows 1,200, but ChatGPT
rejects skill descriptions longer than 1,024, so stay under the lower bar.
- Lead with what it does, in the words a colleague would use.
- Include the trigger phrases from the interview, quoted, as they would be
typed.
- End with one sentence on what it is **not** for, naming the sibling skill.
- No "Use when the user…" filler. Every sentence should either help the
assistant recognise the moment or rule one out.
## Step 6 — Check, then package
Run `references/checklist.md` top to bottom and fix what fails. Then present:
```markdown
**<Title>** · `<slug>` · <tag> · <roles>
Tools: <resolve tool> → <answer tool>
Files: SKILL.md[, references/<name>.md …]
<the full SKILL.md, then each sibling file, each in its own code block>
**Next:** see "Getting the skill live" below.
```
Where files can be created, write the folder `<slug>/SKILL.md` plus any
`references/`, `assets/` or `scripts/` files and offer the zip. Where they
cannot, the code blocks are the deliverable.
## Getting the skill live
Give the user these steps after the package:
- **For the whole team (recommended):** in the Zime dashboard, open Skills →
Upload and drop the folder as a zip (or paste the SKILL.md into a new skill),
set visibility, and publish. Zime syncs it to your team's Zime plugin, so it
reaches everyone who has the plugin installed.
- **Just for yourself in the ChatGPT desktop app:** start a Work chat, type
`@skill-creator` and paste the SKILL.md, or add the folder under **Skills** in
the sidebar. Skills added this way work only in the desktop app. To use the
skill on chatgpt.com or mobile, publish it from the Zime dashboard instead.
Run a published skill with `@<slug>`, or `/<slug>` in the ChatGPT desktop app.
## Rules this skill enforces in every draft
- One skill, one job. Two outputs means two skills.
- Resolve before you answer. Ambiguous means ask, never pick.
- Never answer from memory or chat history while the tool is available, and
the draft must say so in those words.
- Quotes come only from a verbatim tool. Never from an agent's paraphrase.
- Relay agent output as-is. No re-ranking, merging, rounding or additions.
- Unknown is a finding. An empty dimension is reported, not filled.
- Time words go in date fields, not in the query, unless the profile says the
tool wants them in the query.
- Every draft has a local mode, even if it is one line saying what it cannot
do without the connector.
- No instructions that depend on one assistant's features, such as rendering
an artifact or a placeholder like `$ARGUMENTS`. Write plain markdown output
that any assistant can produce.
- No step that tells the assistant to use a different connector. A skill
uses the tools of the connector it was built for.
## Tips
1. **Start from a prompt you already reuse.** If you keep pasting the same
ask into ChatGPT, that ask is the interview.
2. **Bring the three trigger phrases.** The description is only as good as
the phrasings it was written for.
3. **Narrow beats broad.** "Renewals with no exec sponsor" builds a sharper
skill than "renewal risk".
4. **Test the description on the negative prompt.** If the one prompt that
should not trigger it plausibly would, the last sentence of the
description is not doing its job.
## Local mode (no connector connected)
Build from the profile files alone. `references/connector-zime.md` is static
and complete, so a Zime skill can be drafted without the connector present.
Say so, and tell the user the tool names should be verified against their
connected Zime before they publish.
## What this sends where
At the start, this skill calls the Zime connector tool `skill_used`, which
records the skill's id, version and name with your user and session in
Zime's usage log. Beyond that it only writes text. If, and only if, you ask
it to read the tools of a connector that is connected in this chat, it lists
those tools from their descriptions; no call is made to them. The Zime
profile in `references/` is read locally.
## Related Skills
- **review-call**, **review-account**, **call-prep** — the reference
implementations this skill copies its shape from
- **follow-up**, **create-sales-asset** — examples of a skill whose output is
a draft rather than an analysis
Referenced files: 4 — file references are metadata, not package contents.
