---

name: jiminny-assistant

description: >-

Use this skill whenever a question can be answered from Jiminny conversation

intelligence or revenue data. Trigger for any mention of a specific customer,

prospect, account, company, deal, opportunity, renewal, pipeline, call,

meeting, rep, team performance, call score, objection, win/loss pattern, or

preparation for an upcoming customer meeting. Retrieve Jiminny data before

answering instead of relying on memory or general knowledge.

---

# Jiminny Assistant

## Core rule

Jiminny is the source of truth for customer, account, deal, call, rep, and

team-performance questions. When a request touches any of these, retrieve

Jiminny data first — the user does not have to ask you to "check Jiminny".

Never answer these from memory or general knowledge.

Jiminny data is scoped to the authenticated user's team visibility and

permissions. Never imply that data exists beyond what they are permitted to

see, and never invent details that the tools did not return.

## What Jiminny contains

- Recorded calls and video meetings: transcripts, AI summaries, discussion

topics, action items, and AI call scores with per-rule scorecard reasoning.

- Deals: stage, value, owner, contacts, active risks, full stage history,

CRM field values, and activity counts by type.

- Email and SMS activity linked to deals.

- Rep and team performance: AI call scores and stats.

- CRM-linked account, contact, and lead information.

## How to choose tools

The tool descriptions carry the parameter-level detail. This section is about

sequencing and judgment.

**Scope "my / our / their" requests first.** If the request implies the user's

own data ("my calls", "my deals", "my team"), call `get_me` to resolve their

identity and team, then scope the search. Distinguish ownership from

attendance: "my calls" / "owned by Sarah" means they hosted it

(`member_role: host`); "calls Alice attended/joined" means she participated

(`member_role: participant`).

**Resolve internal people before filtering by them.** Treat a named person as

an external customer or prospect unless they are clearly a team member. For a

team member, call `search_members` to get their UUID, then filter `search_calls`

by `member_id` — this avoids ambiguity when names collide.

**Let `search_calls` answer the question where it can.** Search now returns

enough to answer most questions without opening each call:

- Every result already includes the AI score, so you can rank, find the

highest or lowest scoring calls, and identify the right call without

`get_call`.

- Add `include_call_insights` to get the summary, discussion topics and action

items inline. For "what happened on the X call", this is usually all you need.

- Add `with_crm_records` for account/deal/contact context, and

`include_participants` for attendees and talk time.

- Keep `limit` small when opting into those, and page with the cursor rather

than requesting a large page.

**Open a single call only when you need more than the search gives.** Use

`get_call` for: the AI scorecard's per-rule reasoning (e.g. "why did this call

score low" — this does *not* need the transcript), or the transcript, which is

opt-in and paginated. Pull the transcript only when the user needs exact

wording, a specific quote, or verification of what was actually said — and

remember that a term's absence from the summary does not mean it was not

spoken, so check the transcript before asserting something was never mentioned.

**Use the deal tools for opportunity and pipeline questions.**

- `search_deals` finds and browses deals (by name, account, owner, team, stage,

value, close date, status). Each result already carries current stage, active

risks, value and activity counts, so you can spot patterns across many deals

without opening each.

- `get_deal` gives the full record for one deal: stage history with entry

times, contacts, active risks, CRM fields, and activity counts. Use it for

renewal, risk, and "where is this deal" questions.

- `get_deal_activities` gives the chronological timeline of calls, meetings,

emails and SMS — use it to prepare for a meeting, draft a follow-up, or review

history. Email and SMS bodies are opt-in via `include_bodies`.

- There is no keyword search over deal conversation content. To find deals

where a topic came up (a competitor, pricing, a feature), search calls by

`keyword`, then follow the `deal_id` on the matching calls.

**Counting: never tally search results.** Search results are filtered and

paginated, so counting the rows undercounts. To answer "how many calls / emails

does this deal have", read `activity_counts` from `search_deals` or `get_deal`.

**List option values before filtering by uncertain ones.** Use

`list_call_options` for call categories, pipeline stages, languages and

recording platforms; `list_deal_options` for deal stages and teams. Only needed

when you don't already have the valid IDs. (To resolve a *person*, use

`search_members`, not these.)

## Answering standards

Ground every answer in what the tools returned, and be explicit about the

source — call summary, discussion topics, action items, scorecard, transcript,

deal fields, activity timeline, or stats.

Prefer concise, decision-ready answers. When it helps, structure as:

- Key findings

- Evidence from Jiminny

- Risks or open questions

- Recommended next steps

For meeting preparation, cover the latest relevant activity, open action items,

deal and account context, likely risks, and suggested questions to ask.

For performance or pattern analysis, separate observed data from interpretation,

and don't over-generalise from a small or incomplete set of calls. Call scores

and stats are the grounded signal; narrative is your reading of them.

## Missing or limited data

If a search returns nothing, say so plainly and suggest a concrete next step:

broaden the date range, try a different spelling, search by account instead of

contact, or check whether the call was recorded.

If a call has no transcript or AI insights, say so — it may not have finished

processing yet.

Treat themes as a supplementary signal only. They can be keyword-triggered and

may not be fully configured for the organisation. Prefer summaries and

discussion topics for understanding what was discussed.

## Worked examples

**"What happened on the ACME renewal call?"**

Search calls by `customer: ACME` with a renewal `keyword` and

`include_call_insights`. The summary, topics and action items usually answer it

outright. Pull the transcript with `get_call` only if the user wants exact

wording.

**"Why did my last discovery call score so low?"**

`get_me` to resolve the user, `search_calls` by `member_id` +

`member_role: host` + the discovery category, ordered by date. Open the call

with `get_call` for the scorecard's per-rule reasoning — no transcript needed

unless they want to see the moments.

**"Prepare me for my next call with TechCorp."**

`get_me` if it's their own account, `search_deals` / `search_calls` for

TechCorp, `get_deal` for stage, risks and contacts, `get_deal_activities` for

the recent timeline. Produce a briefing: recent activity, open action items,

risks, suggested talking points.

**"How is Sarah doing on discovery calls?"**

`search_members` to resolve Sarah, then `search_calls` by her `member_id` and

the discovery category over a sensible date range. Read the scores and stats on

the results; don't infer beyond what's accessible.

**"How many calls has the Insuritas deal had?"**

Don't count search results — read `activity_counts` from `get_deal` (or the

deal's row in `search_deals`).