v0.3.3 to v0.3.4

2 added, 2 removed. Audit A to A.

---

name: meeting-inspector

description: Deep-dives into a single Chili Piper meeting — booking trigger, routing path, rep assignment, and outcome — to diagnose what happened and surface a next action.

- version: 0.3.3

- api_note: "concierge-logs: optional page/pageSize pagination added (DISTRO-4576, max 500 per page); Quick API table and Step 3b updated; 2026-07-31: CEH-10893 (edge PR #1021) — meeting-get and meeting-list-put now return `sourceUrl` (booking-page URL the guest came from, Option[String]) and `sourceUrlParams` (parsed UTM/query params, Option[Map[String,String]]) directly on the meeting object; api-reference § Meeting summary fields updated. 2026-08-03: CEH-10905 (edge PR #1031) — concierge-list-routers now includes `formFields` on each router — a list of ConciergeFormField objects (label, requirement, fieldType with options, order, description, placeholder) for each Chili-webform guest field; always empty for third-party webform routers."

+ version: 0.3.4

+ api_note: "concierge-logs: optional page/pageSize pagination added (DISTRO-4576, max 500 per page); Quick API table and Step 3b updated; 2026-07-31: CEH-10893 (edge PR #1021) — meeting-get and meeting-list-put now return `sourceUrl` (booking-page URL the guest came from, Option[String]) and `sourceUrlParams` (parsed UTM/query params, Option[Map[String,String]]) directly on the meeting object; api-reference § Meeting summary fields updated. 2026-08-03: CEH-10905 (edge PR #1031) — concierge-list-routers now includes `formFields` on each router — a list of ConciergeFormField objects (label, requirement, fieldType with options, order, description, placeholder) for each Chili-webform guest field; always empty for third-party webform routers. 2026-09-04 (internal consistency fix): references/anomaly-detection.md previously flagged 'Routing fallthrough' on a null/blank matchedPath, contradicting the CEH-10893-era model where matchedPath is an object with a route.type discriminator (RuleRoute | CatchAllRoute). Corrected: Routing fallthrough (Medium) = matchedPath.route.type == 'CatchAllRoute'; a missing routing log OR a null/blank matchedPath belongs to the 'Unrouted meeting' row (Low)."

references:

- api-reference

- routing-trace

- anomaly-detection

- output-format

inputs:

- name: meeting_id

type: string

description: "Chili Piper meeting ID. Provide this OR guest_email."

required: false

- name: guest_email

type: string

description: "Guest email. Used to find their most recent meeting when meeting_id is unknown."

required: false

- name: date_range

type: string

description: "Search window when using guest_email: 'last-7-days', 'last-30-days', or 'YYYY-MM-DD:YYYY-MM-DD'."

required: false

default: "last-30-days"

- name: workspace

type: string

description: "Workspace name or ID to scope the search. Omit for org-wide."

required: false

outputs:

- name: meeting_summary

description: Core facts — status, scheduled time, guest, assigned rep, booking timestamp

- name: routing_trace

description: Full path from trigger to assignment — trigger type, router, matched rule, source URL

- name: anomalies

description: Flags for issues detected (no-show, late cancellation, rep mismatch, routing fallthrough)

- name: recommended_action

description: Suggested next step for the human based on what happened

tools_required: [chili-piper-mcp]

human_decision_point: "Review anomalies and decide: rebook, follow up with guest, or fix the underlying routing rule"

writes_to: "Nothing — read-only diagnostic tool"

---

# Meeting Inspector

You are a GTM diagnostic analyst. Reconstruct the full lifecycle of a single meeting — how the lead arrived, which router and rule matched, who got assigned, and what the outcome was. Flag anything wrong and recommend a next step.

> **Prefer live data over training.** Chili Piper's field names and tool signatures change. Always load `references/api-reference.md` before making MCP calls — it documents exact field names, status values, and known gotchas.

## When to use

- A rep says "a meeting went wrong — can you check what happened?"

- You need to understand why a lead was (or wasn't) assigned to a specific rep

- Investigating a no-show or late cancellation

- Auditing whether CRM write-backs fired correctly after a booking

## Inputs

|-------|:--------:|---------|------------------|

| `meeting_id` | — | — | Chili Piper meeting ID. Provide this OR `guest_email`. |

| `guest_email` | — | — | Guest email; used to find their most recent meeting when `meeting_id` is unknown. |

Provide either `meeting_id` or `guest_email`. If neither is given, ask for it in one sentence rather than guessing.

## Quick API reference

| Tool | What it returns |

|------|----------------|

| `meeting-get` | Single meeting by ID — full detail |

| `meeting-list-put` | Paginated meetings by date range (max 7 days per call) |

| `concierge-list-routers` | All routers in a workspace; each router now includes `formFields` (Chili-webform guest fields with label, type, options, requirement, and order; empty for third-party webforms — CEH-10905) |

| `concierge-logs` | Routing decisions per router (max 30-day window; max 500 logs per page — paginate with `page: 0, 1, ...`) |

| `workspace-list` | All workspaces |

See `references/api-reference.md` for full field names, status codes, trigger types, and known gotchas.

## Process

### Step 1 — Validate inputs and locate the meeting

Provide either `meeting_id` or `guest_email`. If neither is given, ask:

*"Which meeting should I inspect? Provide a meeting ID or the guest's email address."*

If `workspace` is a name (not ID), resolve it via `workspace-list`.

- **Path A** (`meeting_id`): call `meeting-get` directly.

- **Path B** (`guest_email`): chunk `date_range` into ≤7-day windows and call `meeting-list-put` per chunk. Stop as soon as a match is found. If multiple meetings match, show a numbered list and ask which one to inspect.

Tool envelopes and the 7-day window → `references/api-reference.md` § Hard API limits.

### Step 2 — Build the meeting summary

Extract: meeting ID, status, scheduled time, booked-at, lead time, guest email, assigned rep. Also extract `sourceUrl` and `sourceUrlParams` if present on the meeting object — these are optional fields added in CEH-10893 and surface the booking-page URL and its parsed UTM/query parameters.

Both tools use `meetingStatus`, but the meeting-id and time fields differ between them (`meetingId`/`dateTime.start` in list vs `id`/`activities[]` in get). Correct field names → `references/api-reference.md` § Critical field name differences; per-field sources → `references/api-reference.md` § Meeting summary fields.

Lead time interpretation: < 2 h (same-day), 2–24 h (next-day), 1–3 d (short), 4–7 d (standard), > 7 d (long — elevated no-show risk).

### Step 3 — Fetch the routing trace

Skip if the meeting's `bookedAt` is > 30 days ago; note this in output.

**3a. List all routers:**

```

tool: concierge-list-routers

args:

workspaceId: <resolved workspace ID, or omit for all>

```

**3b. For each router, call `concierge-logs`:**

```

tool: concierge-logs

args:

workspaceId: <routers[N].workspaceId>

routerId: <routers[N].router.id>

start: 1 day before meeting's `bookedAt`

end: 1 day after meeting's `bookedAt`

page: 0

pageSize: 500

```

For a narrow ±1-day window a single page is virtually always sufficient; paginate only if the response is exactly `pageSize` entries.

Full step-by-step procedure including how to match a log entry to the meeting → `references/routing-trace.md` § Matching a log entry to the meeting.

### Step 4 — Detect anomalies

Complete anomaly table and severity levels → `references/anomaly-detection.md` § Anomaly table.

### Step 5 — Recommend a next action

- **NoShow** → suggest rebook link within 2 hours; note if long lead time contributed

- **Late cancellation** → check whether guest or rep cancelled; suggest agenda clarity for low-intent leads

- **Rep mismatch** → check Salesforce ownership staleness

- **Routing fallthrough** → audit router rules for this lead's profile

- **Completed, no anomalies** → "No issues detected."

### Step 6 — Output

Exact table structure → `references/output-format.md` § Template.

## Preflight audit

Verify before writing output (this skill is read-only — no mutation step):

- [ ] Exactly one meeting is resolved (either `meeting_id` given, or a single `guest_email` match chosen).

- [ ] Workspace name resolved to an ID via `workspace-list` when `workspace` was a name.

- [ ] Field names taken from `references/api-reference.md`, not guessed (`meetingStatus`, `meetingId`/`id`, `dateTime.start`, `hostId`/`hostEmail`/`hostName`).

- [ ] No `meeting-list-put` call spans more than 7 days; no `concierge-logs` call spans more than 30 days or fetches fewer pages than needed (paginate until empty or short page).

- [ ] Routing trace either populated, or explicitly noted as unavailable (>30 days) / no-log-found.

- [ ] Every anomaly row in `references/anomaly-detection.md` § Anomaly table was checked.

## Checkpoint

This is a read-only diagnostic: present the meeting summary, routing trace, anomalies, and a single recommended action, then stop. Let the human decide the next step — **review anomalies and decide: rebook, follow up with guest, or fix the underlying routing rule.** Do not act on the recommendation yourself.

## Data handling

- **PII present:** guest email, rep email

- **Storage:** ephemeral — no data persists after the skill completes

- **Writes:** none — read-only