Update to Chili Piper

{
  "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",
  "included_files": [
    {
      "relative_path": "references/api-reference.md",
      "size_in_bytes": 3100
    },
    {
      "relative_path": "references/diagnosis.md",
      "size_in_bytes": 2073
    },
    {
      "relative_path": "references/output-format.md",
      "size_in_bytes": 1029
    }
  ],
  "name": "concierge-debugger",
  "skill_md_contents": "---\nname: concierge-debugger\ndescription: 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\nversion: 0.2.6\napi_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.\"\nreferences:\n  - api-reference\n  - diagnosis\n  - output-format\ninputs:\n  - name: guest_email\n    type: string\n    description: \"Email address of the lead who did not book\"\n    required: true\n  - name: router\n    type: string\n    description: \"Router name or slug to search in. Omit to search all routers.\"\n    required: false\n  - name: date_range\n    type: string\n    description: \"When the lead submitted: 'today', 'last-7-days', or 'YYYY-MM-DD:YYYY-MM-DD'\"\n    required: false\n    default: \"last-7-days\"\noutputs:\n  - name: routing_session\n    description: The concierge log entry for this lead — trigger, matched route, assignee, status\n  - name: diagnosis\n    description: Plain-language explanation of what happened and why\n  - name: fix\n    description: Specific change to make in the router to prevent recurrence\ntools_required: [chili-piper-mcp]\nhuman_decision_point: \"Review the diagnosis and decide: fix the routing rule, rebook the lead manually, or escalate to engineering\"\nwrites_to: \"Nothing — read-only diagnostic\"\n---\n\n# Concierge Debugger\n\nYou 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.\n\n> **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).\n\n## When to use\n\n- A lead submitted a form but no meeting was booked, and you need to know why.\n- You need to confirm whether a specific lead was routed at all, and to whom.\n- Deciding whether a non-booking is a routing-rule problem, an availability problem, or a UX/delivery problem.\n\n## Inputs\n\n| Input | Required | Default | What it controls |\n|-------|:--------:|---------|------------------|\n| `guest_email` | ✅ | — | Email address of the lead who did not book. |\n| `router` | — | all routers | Router name or slug to search in. Omit to search all routers. |\n| `date_range` | — | `last-7-days` | When the lead submitted: `today`, `last-7-days`, or `YYYY-MM-DD:YYYY-MM-DD`. |\n\nIf `guest_email` is missing, ask for it in one sentence rather than guessing.\n\n## Process\n\n### Step 1 — Find the router(s) to search\n\nIf `router` is specified, call `concierge-list-routers` and find the matching router by name or slug.\n\nIf no `router` specified, fetch all routers across all workspaces:\n\n```\ntool: workspace-list\nargs:\n  pagination:\n    page: 0\n    pageSize: 100\n```\n\n```\ntool: concierge-list-routers\nargs:\n  workspaceId: <workspace.id>\n```\n\nRouter 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.\n\nThe 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.\n\n### Step 2 — Search logs for the lead\n\nFor each router (or the specified router):\n\n```\ntool: concierge-logs\nargs:\n  workspaceId: <routers[N].workspaceId>\n  routerId: <routers[N].router.id>\n  start: <ISO-8601 start of date_range>\n  end: <ISO-8601 end of date_range>\n  guestEmail: <guest_email>\n  page: 0\n  pageSize: 100\n```\n\nThe 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.\n\nIf found: store the log entry and stop searching other routers.\nIf not found in any router: use the \"no session found\" report → `references/output-format.md` § If no session found.\n\n### Step 3 — Diagnose the outcome\n\nRead 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`.\n\n### Step 4 — Output\n\nExact layout → `references/output-format.md` § Template.\n\n## Preflight audit\n\nVerify before writing output:\n\n- [ ] `guest_email` present.\n- [ ] Field names taken from `references/api-reference.md`, not guessed.\n- [ ] `concierge-logs` window ≤ 30 days, every call carried `routerId` + `guestEmail`, and paginated only if the response was exactly `pageSize` entries.\n- [ ] Outcome interpreted from the literal `status` + `matchedPath` (no assumed status enum).\n- [ ] Any reported assignee `userId` resolved to a name via `user-find-by-ids`.\n\n## Checkpoint\n\nPresent the routing session, diagnosis, root cause, and fix, then stop for the human:\n\n*\"Should I make the fix in the router, or would you like to manually rebook this lead first?\"*\n\nThe human decides: fix the routing rule, rebook the lead manually, or escalate to engineering.\n\n## Data handling\n\n- **PII present:** guest email used for lookup and display\n- **Storage:** ephemeral — nothing persists after the skill completes\n- **Writes:** none — read-only diagnostic\n"
}