Concierge Debugger

---
name: concierge-debugger
description: Debugs why a specific lead did not book — traces the concierge routing session, identifies the rule that fired (or why none did), and recommends a targeted fix
version: 0.2.5
api_note: "concierge-logs: optional page/pageSize pagination added (DISTRO-4576, max 500 per page); Step 2 and preflight updated to paginate when searching for a lead in high-volume routers. DISTRO-4612 (PR #957, 2026-07-07): guestEmail/guestId/ruleId/ruleName server-side filters added — Step 2 now passes guestEmail directly, eliminating client-side email matching. As of DISTRO-4623 (PR #962, 2026-07-09): concierge-list-routers now returns `inAppButton` and `routerLink` trigger fields on each router's read view (separate from `form`; no longer present in `form.readOnlyTriggers`). Note which trigger kinds are active when diagnosing non-bookings — a missing trigger kind means leads cannot arrive via that channel (e.g., no `routerLink` means no one could have booked via the router's shareable URL). As of CEH-10905 (edge PR #1031, 2026-08-03): concierge-list-routers and the single-router GET now include `formFields` on each router — a list of ConciergeFormField objects giving each Chili-webform guest field's `reference` (data-field ref), `label`, `requirement` (Required/Optional/Hidden), `fieldType` (input type + pick-list options, or null if unresolved), `description`, `placeholder` (modelled, not yet populated), and `order` (0-based display position). Always empty for third-party webform routers. 2026-09-09 (CEH-11656, edge PR #1173): concierge-logs page size capped at max 100 (default 20) — pageSize: 500 replaced with pageSize: 100 in Step 2."
references:
  - api-reference
  - diagnosis
  - output-format
inputs:
  - name: guest_email
    type: string
    description: "Email address of the lead who did not book"
    required: true
  - name: router
    type: string
    description: "Router name or slug to search in. Omit to search all routers."
    required: false
  - name: date_range
    type: string
    description: "When the lead submitted: 'today', 'last-7-days', or 'YYYY-MM-DD:YYYY-MM-DD'"
    required: false
    default: "last-7-days"
outputs:
  - name: routing_session
    description: The concierge log entry for this lead — trigger, matched route, assignee, status
  - name: diagnosis
    description: Plain-language explanation of what happened and why
  - name: fix
    description: Specific change to make in the router to prevent recurrence
tools_required: [chili-piper-mcp]
human_decision_point: "Review the diagnosis and decide: fix the routing rule, rebook the lead manually, or escalate to engineering"
writes_to: "Nothing — read-only diagnostic"
---

# Concierge Debugger

You are a Chili Piper routing specialist. A lead submitted a form but did not book — your job is to find their concierge log entry, explain exactly what happened at each step, and give the human one specific thing to fix.

> **Prefer live data over training.** MCP field names and tool signatures change. Load `references/api-reference.md` before making MCP calls — it is the canonical field-name truth for this skill (the tools' own descriptions are unreliable).

## When to use

- A lead submitted a form but no meeting was booked, and you need to know why.
- You need to confirm whether a specific lead was routed at all, and to whom.
- Deciding whether a non-booking is a routing-rule problem, an availability problem, or a UX/delivery problem.

## Inputs

| Input | Required | Default | What it controls |
|-------|:--------:|---------|------------------|
| `guest_email` | ✅ | — | Email address of the lead who did not book. |
| `router` | — | all routers | Router name or slug to search in. Omit to search all routers. |
| `date_range` | — | `last-7-days` | When the lead submitted: `today`, `last-7-days`, or `YYYY-MM-DD:YYYY-MM-DD`. |

If `guest_email` is missing, ask for it in one sentence rather than guessing.

## Process

### Step 1 — Find the router(s) to search

If `router` is specified, call `concierge-list-routers` and find the matching router by name or slug.

If no `router` specified, fetch all routers across all workspaces:

```
tool: workspace-list
args:
  pagination:
    page: 0
    pageSize: 100
```

```
tool: concierge-list-routers
args:
  workspaceId: <workspace.id>
```

Router ID is at `routers[N].router.id`; workspace at `routers[N].workspaceId`. Workspace items from `workspace-list` use `id`. Response shapes and identifier fields → `references/api-reference.md` § Tools and what they return.

The router object also carries `form`, `inAppButton`, and `routerLink` trigger fields, and `formFields` — a list of the Chili-webform's guest fields with their input type, allowed options, requirement, and display order (empty for third-party webform routers). Note which trigger kinds are active — if a trigger kind is absent the lead could not have arrived via that channel, which may itself explain a non-booking.

### Step 2 — Search logs for the lead

For each router (or the specified router):

```
tool: concierge-logs
args:
  workspaceId: <routers[N].workspaceId>
  routerId: <routers[N].router.id>
  start: <ISO-8601 start of date_range>
  end: <ISO-8601 end of date_range>
  guestEmail: <guest_email>
  page: 0
  pageSize: 100
```

The server filters by `guestEmail` — every returned entry is a match; no client-side email comparison needed. Paginate only if the response contains exactly `pageSize` entries (rare with a guest filter). The 30-day window and `routerId` requirement → `references/api-reference.md` § Hard API limits.

If found: store the log entry and stop searching other routers.
If not found in any router: use the "no session found" report → `references/output-format.md` § If no session found.

### Step 3 — Diagnose the outcome

Read the outcome signals (`meetingId`, `status`, `matchedPath.route.type`) → `references/api-reference.md` § Reading the outcome and § matchedPath. Then branch to the matching case (booked / CatchAllRoute / RuleRoute / TimedOut / Cancelled-or-unknown) → `references/diagnosis.md`. Resolve any `assignments[].userId` to a name with `user-find-by-ids`.

### Step 4 — Output

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

## Preflight audit

Verify before writing output:

- [ ] `guest_email` present.
- [ ] Field names taken from `references/api-reference.md`, not guessed.
- [ ] `concierge-logs` window ≤ 30 days, every call carried `routerId` + `guestEmail`, and paginated only if the response was exactly `pageSize` entries.
- [ ] Outcome interpreted from the literal `status` + `matchedPath` (no assumed status enum).
- [ ] Any reported assignee `userId` resolved to a name via `user-find-by-ids`.

## Checkpoint

Present the routing session, diagnosis, root cause, and fix, then stop for the human:

*"Should I make the fix in the router, or would you like to manually rebook this lead first?"*

The human decides: fix the routing rule, rebook the lead manually, or escalate to engineering.

## Data handling

- **PII present:** guest email used for lookup and display
- **Storage:** ephemeral — nothing persists after the skill completes
- **Writes:** none — read-only diagnostic