Update to Crisphive

{
  "name": "crisphive-roster-sync",
  "description": "Manage a field-operations team in Crisphive — create, update, and remove technicians and keep their skills, service areas, crew relations (leads/buddies), and vehicles in sync, e.g. when onboarding staff or syncing from an HR system. Use when the user wants to add or remove a technician, change someone's skills or coverage area, or set up who works with whom.",
  "included_files": [],
  "skill_md_contents": "---\nname: crisphive-roster-sync\ndescription: Manage a field-operations team in Crisphive — create, update, and remove technicians and keep their skills, service areas, crew relations (leads/buddies), and vehicles in sync, e.g. when onboarding staff or syncing from an HR system. Use when the user wants to add or remove a technician, change someone's skills or coverage area, or set up who works with whom.\n---\n\n# Manage the technician roster with Crisphive\n\nThe technician roster feeds the scheduling engine directly: skills, service\nareas, start locations and crew relations all change who gets matched to\nwhich job. Keep them accurate.\n\n## Environments: sandbox vs production\n\nThis skill works identically in BOTH environments — same tools, same fields,\nsame responses. The credential decides which one you are in:\n\n- **Sandbox** — API key `chsk_test_…`, or an OAuth connection authorized from\n  a sandbox dashboard session. The sandbox has its OWN isolated roster: test\n  technicians here never appear in the live team and receive no\n  notifications. One extra rule applies: Owner/Administrator role groups\n  cannot be created in sandbox (operational roles like Technician work\n  everywhere).\n- **Production** — API key `chsk_live_…`, or an OAuth connection authorized\n  from a live session. Creating a member with an email/phone sends them a\n  real \"you've been added\" notification, and roster changes immediately\n  affect real job matching. Create real people only, and confirm removals\n  with the user before calling `deleteTechnician`.\n\nYou cannot switch environments with a parameter; reconnect with the other\ncredential.\n\n## Creating a technician\n\n`createTechnician` — required fields:\n\n- `business_group_id` — the role group (Technician, Supervisor, …).\n  **Group IDs are not discoverable through this API**; the business copies\n  them from the Crisphive dashboard (Settings → Permissions). Ask the user\n  for it if you don't have one from an earlier call in this conversation.\n- `full_name`.\n- At least one of `email` / `phone`. Phone numbers are validated as REAL\n  E.164 numbers (libphonenumber: real dial code + per-country pattern) —\n  placeholder numbers are rejected with `PHONE_INVALID`. If neither contact\n  is valid you get `TECHNICIAN_CONTACT_REQUIRED`.\n\nStrongly recommended at create time:\n\n- `assignment_tier` — how the crew matcher treats them: `lead` (can head a\n  job), `buddy` (crew helper), `float` (excluded from auto crew-assign).\n- `start_location_type` (`home` | `office`) **plus explicit\n  `start_location_lat` / `start_location_long`** — the engine computes travel\n  times from this point. Note: choosing `office` snapshots the business\n  location at creation time; set the coordinates explicitly to be safe.\n- `service_area_ids` — which geographic areas they cover (discover via\n  `listServiceAreas`). A technician with no service area is never matched.\n- `buddy_ids` (when creating a lead) or `lead_ids` (when creating a buddy) —\n  see crew relations below.\n\nNo invite email is sent; sign-in is passwordless and handled by the platform\nlater.\n\n## Keeping attributes in sync\n\n- Skills: `replaceTechnicianSkills` (PATCH, replace-semantics — send the FULL\n  list; `[]` clears). Discover skill IDs via `listSkills` /\n  `listSkillCategories`. Skills matter twice: as a hard filter when a job\n  demands them and as a soft ranking signal.\n- Service areas: `replaceTechnicianServiceAreas` (replace-semantics).\n- Vehicles: `replaceTechnicianVehicles` — the vehicles this technician can\n  use (discover via `listVehicles`). Vehicle-to-tech links are edited only\n  from the technician side.\n- Profile fields: `updateTechnician` is a FULL replace — read the current\n  record with `getTechnician` first and send every field back, changing only\n  what the user asked for.\n\n## Crew relations (leads & buddies)\n\n- The relation is DIRECTIONAL and owned by the lead: a lead's `buddy_ids`\n  lists who can crew under them. `replaceTechnicianBuddies` edits a lead's\n  list (replace-semantics; self-buddy is rejected).\n- `replaceTechnicianLeads` is the buddy-side write of the SAME relation — it\n  adds/removes this technician in the named leads' buddy lists.\n- Buddies matter for multi-person jobs: the matcher prefers a lead's own\n  buddies when building a crew.\n\n## Removing a technician\n\n- `deleteTechnician` removes them from the active roster and automatically\n  scrubs references (buddy lists, vehicle ownership). It is a soft delete\n  server-side, but treat it as destructive: confirm with the user first.\n- Suspending rather than removing (status changes) is a dashboard operation,\n  not available through this API.\n\n## Verifying\n\n`listTechnicians` / `getTechnician` embed the synced state: skills, service\nareas, buddies/leads, vehicles, tier, start location. After a batch of\nchanges, read back and summarize what changed.\n\n"
}