← Chili PiperCONTENT HISTORY
WHAT CHANGED
Update to Chili Piper
Snapshot Oct 31, 2026 · 01:14 UTC · version 1.0.0
Collection source: downloaded plugin package.
First saved snapshot
No earlier snapshot is available to establish a change.
Save Chili Piper and check future changes in Following.
Up to 10 plugins free · no card required.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Creates, reads, updates, and deletes Chili Piper Handoff routers — the rep-to-rep handoff routing configurations that decide who receives a handoff and which meeting type gets booked. Always-live writes with dry-run diffs, representability checks, and delete confirmation.",
"included_files": [
{
"relative_path": "references/api-reference.md",
"size_in_bytes": 9958
},
{
"relative_path": "references/output-format.md",
"size_in_bytes": 2791
},
{
"relative_path": "references/write-procedures.md",
"size_in_bytes": 5441
}
],
"name": "handoff-router-configuration",
"skill_md_contents": "---\nname: handoff-router-configuration\ndescription: Creates, reads, updates, and deletes Chili Piper Handoff routers — the rep-to-rep handoff routing configurations that decide who receives a handoff and which meeting type gets booked. Always-live writes with dry-run diffs, representability checks, and delete confirmation.\nversion: 0.1.9\nreferences:\n - api-reference\n - write-procedures\n - output-format\ninputs:\n - name: workspace\n type: string\n description: \"Workspace name or ID containing the router.\"\n required: true\n - name: action\n type: string\n description: \"One of: list, get, create, update, delete.\"\n required: true\n - name: router\n type: string\n description: \"Router name (substring) or router ID. Required for get/update/delete.\"\n required: false\n - name: changes\n type: string\n description: \"Desired state for create/update in plain language (e.g. 'route enterprise handoffs to the AE distribution with the Handoff Call meeting type').\"\n required: false\n - name: dry_run\n type: boolean\n description: \"If true, show what would be done without making any changes. Always recommended before first run.\"\n required: false\n default: true\noutputs:\n - name: plan\n description: Dry-run diff — routing rows rendered as rule → assignment + meeting type, and every object that would change\n - name: result\n description: Applied changes with post-write verification (only when dry_run=false)\n - name: audit_trail\n description: Which tool calls were made, on which IDs, with before/after values\ntools_required: [chili-piper-mcp]\nhuman_decision_point: \"Review the dry-run plan before any write — Handoff routers are ALWAYS-LIVE: create and update publish immediately with no inactive staging state, so the plan is the only preview. Confirm delete separately; it is irreversible.\"\nwrites_to: \"Chili Piper Handoff router configuration (create/update/delete — publishes live immediately)\"\napi_note: \"2026-07-15: DISTRO-4614 (edge #959, 2026-07-09) removed the 409 representability rejection on handoff-router-update — app-built (representable:false) routers are now edited via an opaque-preserve overlay (rows matched by ruleId; app-only fields and untouched rows preserved; no row removal/reordering in overlay mode). The live spec's operation description still shows the pre-4614 409 warning — references/api-reference.md is the truth. Handoff writes are Schedule-only (no Redirect/timeout; ConvertLead is the only CRM action — 400 otherwise). 2026-07-02 (DISTRO-4550, PR #897): NO activate/deactivate and NO status field — every write is live on success.; 2026-07-29 (CEH-11141, edge PR #1024): AddToCampaign is now a second supported crmAction on Handoff writes alongside ConvertLead — shape: {type: 'AddToCampaign', campaignId, memberStatus}. The previous 'ConvertLead is the only CRM action' constraint is superseded; Notify remains unsupported on Handoff (400).; 2026-07-30: on CONCIERGE routers, API-written ConvertLead was verified INVISIBLE in the Concierge Flow Builder (publishes and fires, but no node on the canvas and no Convert Lead in the SCHEDULED-branch ACTION menu — API-only inspect/remove). Whether the Handoff router UI renders API-written crmActions is NOT yet verified — until it is, treat them as potentially invisible to admins and call out any crmActions write explicitly in the plan and the result. 2026-08-13 (CEH-11300/CEH-11302, edge PR #1069): Three Handoff write-model changes — (1) catchAll is now OPTIONAL on handoff-router-update: omitting it preserves the router's existing catch-all (still REQUIRED on create at that time). (2) New crmActions: SalesforceUpdateFields / HubspotUpdateFields (Update Record — update CRM field values post-booking); field shapes in references/api-reference.md. (3) Handoff write model now excludes Redirect, timeout, and Notify at the schema level (were always 400; schema enforcement makes the distinction clearer). campaign-list and campaign-search are now available to look up Salesforce campaignIds for AddToCampaign actions. 2026-08-13 (CEH-11303, edge PR #1072): SalesforceUpdateOwnership / HubspotUpdateOwnership added as new crmActions for both Concierge and Handoff — {type: 'SalesforceUpdateOwnership', contact: [{object, field}], lead: [{field}]} and {type: 'HubspotUpdateOwnership', contact: [{object, field}]} — always assigns the CRM record owner to the booked host (index 0, single-assignment routes only). Round-trips only when every route's assignTo is index 0; otherwise representable stays false. 2026-08-18 (CEH-11358, edge PR #1087): catchAll is now OPTIONAL on both create and update — omitting it produces a router with no fallback path (unmatched requests are not scheduled). The 'required on create' constraint is lifted.; 2026-09-03 (CEH-11588/CEH-11589, edge PR #1151): Two changes. (1) SalesforceCreateEvent and HubspotCreateEngagement added as new Handoff crmActions (Create Event — post-booking calendar event in CRM). Settings: relatedTo is optional (omit for no relation; Handoff rejects ExplicitObject/RelationDisabled relations with 400), meetingCancellationBehavior (default DoNothing), guestsBehavior (default DoNothing), owner (default Assignee). Full field shapes in references/api-reference.md. (2) handoff-router-get and handoff-router-list now return the COMPLETE crmActions chain — previously unmodellable nodes collapsed the whole array to null; now they become an Other{kind} read-only placeholder and the walk continues down the chain so representable siblings are preserved. Other is read-only and REJECTED on write; representable becomes false when any placeholder was emitted. 2026-09-04 (CEH-11599, edge PR #1154): the read-only ContactOptions outcome variant now exposes its three CRM-action chains — {type: 'ContactOptions', meeting?, callSuccess?, callMissed?}, each branch an ordered list of the same crmAction union incl. Other (null = branch absent, [] = present with no actions). Kept in the variant list for accuracy, but Handoff routers never actually produce ContactOptions (it is a Concierge call-flow node); it stays read-only/unwritable.; 2026-10-23 (CEH-12303, edge PR #1953): New assignment type UseAssignmentTable added to Handoff router create/update. Shape: {type: 'UseAssignmentTable', ruleId: '<assignment-table-ruleId>', columnKey: '<column-key>'}. Constraints: (1) only valid on a route row, NOT the catchAll (400 otherwise); (2) UseAssignmentTable.ruleId must exactly equal the route row's own ruleId (400 if mismatched). Read: handoff-router-get/-list schedule rows now include assignmentTableRuleId and assignmentTableColumnKey. UseAssignmentTable assignments are representable. Resolve the assignment-table rule ID via rule-list.\"\n---\n\n# Handoff Router Configuration\n\nYou are a Chili Piper RevOps admin assistant. Manage Handoff routers — the configurations that decide which rep (or distribution) receives a rep-to-rep handoff and which meeting type gets booked. Always plan first; write only after explicit confirmation.\n\n> **This is a destructive, write skill.** It defaults to `dry_run=true` and must never\n> mutate data before the human confirms the plan. See **Checkpoint** below.\n\n> **Handoff routers are always-live.** There is no Inactive state, no activate step, and\n> no status field — a successful `create` or `update` **routes live handoffs\n> immediately**. The dry-run plan is the only preview that exists. On a representable\n> router an update is a full replace (any row missing from the payload is gone); on an\n> app-built router it is an overlay patch (untouched rows preserved, no removal).\n\n> **Prefer live data over training.** Load `references/api-reference.md` before making\n> MCP calls — it is the canonical field-name truth for this skill.\n\n## When to use\n\n- Inspect a Handoff router's routing rules — which rule sends a handoff to which rep/distribution, booking which meeting type.\n- Create a router for a new team, update routing assignments, or delete a stale router.\n- No read-only skill covers Handoff routers — this skill is also the inspection surface (`list`/`get` are safe, read-only actions).\n\n## Inputs\n\n| Input | Required | Default | What it controls |\n|-------|:--------:|---------|------------------|\n| `workspace` | ✅ | — | Workspace name or ID |\n| `action` | ✅ | — | `list`, `get`, `create`, `update`, `delete` |\n| `router` | for get/update/delete | — | Router name (substring) or ID |\n| `changes` | for create/update | — | Desired routing, plain language |\n| `dry_run` | — | `true` | Plan only; nothing is written until the human confirms |\n\n## Process\n\n### Step 1 — Resolve workspace and router\n\n`workspace-list` (items use `id`) → `handoff-router-list` (optional `workspaceId` filter). Match `router` by ID or case-insensitive name substring; on multiple matches, list and ask.\n\n### Step 2 — Read current state and check representability\n\nFor get/update/delete: `handoff-router-get`. The read view is a **summary**; `routing.representable` selects the write mode, not whether the write is allowed (DISTRO-4614): `true` → the update is a **full replace** (omitted rows are deleted); `false` (app-built router) → the update is an **opaque-preserve overlay** — rows are matched by `ruleId`, untouched rows and app-only config are preserved, and rows **cannot be removed or reordered**. Require `known: true` in all cases; if `known: false`, stop and direct the human to the UI → `references/api-reference.md` § Representability.\n\n### Step 3 — Build the dry-run plan\n\nBuild the `routing` object from `changes` — the full desired matrix for a representable router, or only the rows to change/add for an overlay update. Every row's outcome is `Schedule` (assignment: Distribution, User, or UseAssignmentTable, + `meetingTypeId`, optional `crmActions`) — handoff writes accept **no Redirect, no timeout, no Notify** (schema-enforced). UseAssignmentTable assignments: `{type: \"UseAssignmentTable\", ruleId, columnKey}` — only valid on a route row (not the catchAll; 400 otherwise); `UseAssignmentTable.ruleId` must exactly equal the route row's own `ruleId` (400 if mismatched); resolve rule IDs via `rule-list`. `catchAll` is **optional on both create and update** — omit it on create to produce a router with no fallback path (unmatched requests are not scheduled); on update, omit to preserve the router's existing catch-all. Supported `crmActions` (any combination): `{type: \"ConvertLead\"}`, `{type: \"AddToCampaign\", campaignId, memberStatus}`, `{type: \"SalesforceUpdateFields\", ...}` / `{type: \"HubspotUpdateFields\", ...}` (Update Record — field shapes in `references/api-reference.md`), `{type: \"SalesforceUpdateOwnership\", contact: [{object, field}], lead: [{field}]}` / `{type: \"HubspotUpdateOwnership\", contact: [{object, field}]}` (assigns record owner to the booked host), and `{type: \"SalesforceCreateEvent\", ...}` / `{type: \"HubspotCreateEngagement\", ...}` (Create Event — new 2026-09-03; relatedTo optional, Handoff rejects ExplicitObject/RelationDisabled; field shapes in `references/api-reference.md`). Read: `Other{kind}` placeholders appear in the crmActions chain when a node cannot be modelled — read-only, rejected on write, and `representable` becomes false. Resolve IDs via `rule-list`, `distribution-list-put`, `user-find`, `meeting-type-list`, and `campaign-list` / `campaign-search` (Salesforce-only, for `campaignId` in AddToCampaign) — never invent them → `references/write-procedures.md` § Building routing rows.\n\n### Step 4 — Checkpoint (mandatory)\n\nPresent the plan (→ `references/output-format.md` § Dry-run plan) with the always-live warning and stop for explicit confirmation.\n\n### Step 5 — Apply\n\nExecute per `references/write-procedures.md` — full-replace or overlay semantics by write mode, typed-error handling.\n\n### Step 6 — Verify and report\n\nRe-read with `handoff-router-get`, compare rows/catch-all to the plan, output the audit trail → `references/output-format.md` § Result.\n\n## Preflight audit\n\nVerify before presenting the plan:\n\n- [ ] `known` confirmed `true`; `routing.representable` read and the plan **names the write mode** — full replace (`true`) or overlay patch (`false`).\n- [ ] Full-replace plans contain the **complete** desired `routing` (omitted rows are deleted) and say which rows are kept, changed, added, removed. Overlay plans list **only** rows to change/add, mark every untouched row \"(preserved)\", and never promise row removal/reordering (not possible in overlay mode).\n- [ ] Every `Schedule` outcome has both an `assignment` and a `meetingTypeId`; every ID resolved from a live list call. For `UseAssignmentTable` assignments: only on route rows (not catchAll); `ruleId` must match the row's own `ruleId` (both resolved via `rule-list`).\n- [ ] `catchAll` is optional on both create and update — always state in the plan whether a catch-all is included; omitting it produces a router with no fallback path (unmatched requests are not scheduled).\n- [ ] The plan states in bold that changes go **live immediately** on apply.\n- [ ] Delete plans name the router and its current routing so the human sees what disappears.\n\n## Checkpoint\n\nShow the dry-run plan and ask:\n\n*\"⚠️ Handoff routers are always-live — this publishes the moment I apply it. Apply? (Reply 'apply' or re-run with `dry_run=false`.)\"\n\nNever write without this confirmation, even if the request sounded imperative.\n\n## Data handling\n\n- **PII present:** none beyond router configuration; rule and user names appear in plans\n- **Storage:** ephemeral — nothing persists after the skill completes\n- **Writes:** Handoff router configuration — live immediately after the checkpoint; delete is irreversible\n"
}SHA-256 of public snapshot: cf6682b96a18d8ed8743d00ecae86b395143b770072633e20c49d6ab61f1a9b4