Update to Crisphive

{
  "name": "crisphive-book-job",
  "description": "Book a field-service job end-to-end with Crisphive — find or create the customer, check real availability windows, create the booking, quote the work, and confirm an exact appointment slot with automatic technician assignment. Use whenever the user wants to schedule, book, or arrange a service visit, repair, installation, or maintenance job for a customer.",
  "included_files": [],
  "skill_md_contents": "---\nname: crisphive-book-job\ndescription: Book a field-service job end-to-end with Crisphive — find or create the customer, check real availability windows, create the booking, quote the work, and confirm an exact appointment slot with automatic technician assignment. Use whenever the user wants to schedule, book, or arrange a service visit, repair, installation, or maintenance job for a customer.\n---\n\n# Book a field-service job with Crisphive\n\nYou are driving a deterministic scheduling engine. Follow the steps in order —\neach step feeds the next. A job cannot be confirmed before it is quoted.\n\nEvery tool returns the envelope `{\"error_code\": 0 | \"CODE\", \"message\": \"…\",\n\"data\": {…}}`. `error_code` 0 = success; otherwise it is a stable string\nexplaining the failure — read it before retrying.\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 starting `chsk_test_`, or an OAuth connection the\n  business owner authorized while their dashboard was in sandbox mode. All\n  data is an isolated test copy: bookings here never reach a real customer\n  and send no real notifications. Use it to experiment freely and to rehearse\n  a flow before running it live.\n- **Production** — API key starting `chsk_live_`, or an OAuth connection\n  authorized from a live dashboard session. Every step below creates or\n  changes REAL business data, and a confirmed booking schedules a REAL\n  technician visit and notifies a REAL customer.\n\nYou cannot switch environments with a parameter; reconnect with the other\ncredential. **In production, recap the details and get the user's explicit\ngo-ahead before step 5 (`confirmJobRequest`).**\n\n## 1. Resolve the customer\n\n- Search first: `listCustomers` with the `q` filter (matches name, phone,\n  email). Reuse the existing customer's `id` if found.\n- Otherwise `createCustomer`. **Include the street address AND\n  `address.latitude`/`address.longitude`** — the engine needs coordinates to\n  compute travel times and match service areas; an address string alone is\n  stored but NOT geocoded server-side. Use coordinates you know with\n  confidence for the stated address, or confirm the location with the user.\n  Pass an `idempotency_key` so a retried create never duplicates.\n\n## 2. Check real availability windows\n\n- `listJobRequestBookingWindows` with `x_timezone` = the CUSTOMER's IANA\n  timezone (e.g. `America/Toronto`). Never invent windows.\n- The response is a grid of days × periods (`morning` / `afternoon` /\n  `evening`). These are *preference windows*, not exact appointment times.\n- Offer the user only windows present in the response.\n\n## 3. Create the booking\n\n- `createJobRequest` with `customer_id` and `job_dates` — an array of\n  `{date: \"YYYY-MM-DD\", periods: [{period: \"morning\"}]}` picked in step 2.\n- Optional: `job_type_id` (discover via `listJobTypes`), `skill_ids`\n  (discover via `listSkills`) when the user described the kind of work, and\n  `description` (free text). Pass an `idempotency_key`.\n- Do not set `priority` unless the job is genuinely urgent (see the\n  crisphive-emergency-dispatch skill); omitted bookings get the business's\n  default priority.\n\n## 4. Quote the work\n\n- `quoteJobRequest` with `job_duration_minutes` (on-site work time) plus\n  `mobilization_minutes` / `demobilization_minutes` (travel/setup before and\n  after). If the user gave no durations, propose sensible ones and confirm\n  with the user before quoting.\n- Quotes are time bundles only — Crisphive job requests carry NO prices,\n  amounts, or currency. Never invent monetary fields.\n\n## 5. Confirm an exact slot\n\n- The confirm API needs an exact start time, not a window. Fetch the exact\n  bookable start times with `listMatchingSlots` (optional `step_minutes`,\n  default 30), then call `confirmJobRequest` with:\n  - `scheduled_at` — the chosen slot's business-local naive datetime\n    (`2026-08-04T09:00:00`, NO timezone offset — take the\n    `business_time.datetime` value from the slot response verbatim).\n  - `status_version` — echo the value from your last `getJobRequest` read to\n    fence against concurrent edits (optional but recommended).\n  - `technician_id` — ONLY when the user explicitly demands a specific\n    person; otherwise omit it and the matching engine auto-assigns the best\n    technician by skills, travel time, and availability.\n- Pass an `idempotency_key`.\n\n## 6. Verify and report\n\n- Read back with `getJobRequest` / `getJobRequestTimeline`: assigned\n  technician, arrival window, scheduled start/end, and the next workflow\n  action. Summarize these for the user.\n\n## Recovering from errors\n\n- `JOB_REQUEST_NO_TECHNICIAN_AVAILABLE` on confirm: that exact time has no\n  feasible technician. Re-run `listMatchingSlots` and offer the nearest\n  alternatives — do not retry the same time.\n- Empty booking windows / empty slots: the business may have no technicians\n  with availability in that service area. Say so instead of inventing times.\n- `JOB_REQUEST_STAGE_CONFLICT` (409): someone changed the job concurrently —\n  re-read with `getJobRequest` and redo the step with the fresh\n  `status_version`.\n- `IDEMPOTENCY_KEY_REUSE` (422): you reused a key with a different body —\n  generate a fresh key.\n\n"
}