← magicplanCONTENT HISTORY

Update to magicplan

Snapshot Sep 30, 2026 · 23:00 UTC · version 1.0.2

Collection source: not recorded for this historical snapshot.

WHAT CHANGED · RULE-BASED ANALYSIS

First saved snapshot

No earlier snapshot is available to establish a change.

Compare saved observations

Download comparison JSON
Full technical diff · 0 changed fields
Full snapshot data
{
  "description": "Prepare a neutral, carrier-ready adjuster handoff package from a magicplan restoration project — project geometry and affected areas, the documentation inventory, the estimate posture, and a clean list of open questions — following the built-in restoration adjuster-handoff playbook plus adjuster communication best practices. Use this whenever someone is getting a job in front of an insurer: \"prepare the adjuster handoff\", \"put together the carrier package for this loss\", \"I need to hand this off to the adjuster\", \"write the adjuster narrative\", \"get this file ready for the insurance company\", or \"summarize this project for the carrier\". Trigger it even when the person only says they're sending a project to an adjuster or carrier and wants it packaged properly.",
  "included_files": [
    {
      "relative_path": "references/handoff-guide.md",
      "size_in_bytes": 3308
    }
  ],
  "name": "magicplan-adjuster-handoff",
  "skill_md_contents": "---\nname: magicplan-adjuster-handoff\ndescription: >-\n  Prepare a neutral, carrier-ready adjuster handoff package from a magicplan restoration project —\n  project geometry and affected areas, the documentation inventory, the estimate posture, and a clean\n  list of open questions — following the built-in restoration adjuster-handoff playbook plus adjuster\n  communication best practices. Use this whenever someone is getting a job in front of an insurer:\n  \"prepare the adjuster handoff\", \"put together the carrier package for this loss\", \"I need to hand this\n  off to the adjuster\", \"write the adjuster narrative\", \"get this file ready for the insurance company\",\n  or \"summarize this project for the carrier\". Trigger it even when the person only says they're sending\n  a project to an adjuster or carrier and wants it packaged properly.\ncompatibility: Requires the magicplan connector (MCP tools) for project and workspace data.\nmetadata:\n  author: magicplan\n  version: \"1.0\"\n---\n\n# magicplan Adjuster Handoff\n\nAssemble a concise, factual package a restoration professional can hand to an insurance adjuster or\ncarrier representative. The tone is measured and neutral throughout — present conditions observed and\nwhat the documentation shows, not advocacy for scope. A clean, honest handoff builds carrier trust; an\noverreaching one invites pushback.\n\nThis skill reads from magicplan only and does not change workspace data. It documents the project state;\nit does not decide coverage — that is the carrier's and adjuster's call.\n\n## Step 1 — Load the built-in playbook\n\nIf restoration resources are available, read the **`restoration://playbooks/adjuster-handoff`** resource\nand follow its review sequence — it is the authoritative structure for this task. The\n`restoration://playbooks/fnol-to-scope` playbook is a useful companion when the handoff also needs to\nframe first-scope reasoning. Combine the playbook's sequence with the template and best practices in\n`references/handoff-guide.md`. If resources are not available, use the reference file alone.\n\n## Step 2 — Ask about carrier-specific requirements\n\nBefore building, ask the user whether they have **carrier-specific requirements** for this handoff, for\nexample:\n\n- The **carrier / program** and any house format or portal it must fit.\n- **Required forms or attachments** the carrier expects (specific documentation, authorizations).\n- **Reference numbers** — claim number, adjuster name/contact, policyholder details.\n- Any **house rules** on tone, itemization, or what to include/exclude.\n\nIf they have a spec, follow it. If not, tell them you'll use standard best practices from the playbook\nand reference file, and proceed. Also ask once for the **company name and contact details** for the\nheader — never assume branding.\n\n## Step 3 — Gather the project documentation\n\nFollowing the playbook sequence, read:\n\n- `get_project_snapshot` — property type, floors, affected rooms, estimates, `plan_id`, `cloud_url`.\n- `get_plan_statistics` — approximate square footage and per-room measurements.\n- `get_project_plan` — affected-area annotations, loss type/category/class if set, equipment placed.\n- `get_plan_forms` — completed workspace custom forms.\n- `get_moisture_readings` — instrument drying history (empty series = a gap to name).\n- `list_project_photos` — photo evidence (counts, captions, URLs); page through `page_info`.\n- `list_project_files` — reports, third-party assessments, other documents.\n- `list_estimates` / `get_estimate` — estimate posture and, if needed, coverage of line items.\n\n## Step 4 — Build the package\n\nProduce the handoff using the structure in `references/handoff-guide.md`: project & affected-area\nsummary, documentation inventory (forms, photos, files, readings — with gaps named), estimate posture\n(what it covers, no opinion on whether it is high or low), and a clean list of open questions sorted into\nfield / adjuster / customer / third-party items, each phrased as a neutral question rather than a demand.\n\nDeliver a polished file (a clean written document; HTML or Word both print well) plus a one-line summary\nin chat. Keep the document neutral and free of magicplan-specific jargon the adjuster would not use.\n\n### Report-gap recommendation\n\nA strong handoff often needs an estimate or report that lives in magicplan and cannot be generated here.\nWhen the package would be materially stronger with something missing — no estimate on file, no formal\nreport, thin photo or moisture documentation — name the gap, give the user the project `cloud_url` so\nthey can generate or capture it in magicplan, and offer to fold it into the package once it exists.\nHanding a carrier a package with visible, acknowledged gaps beats padding it with assumptions.\n\n## Principles\n\n- Neutral and factual. Present conditions observed; do not argue scope or coverage.\n- Separate documented facts from assumptions; label assumptions.\n- Name documentation gaps as neutral open items, not failures.\n- Never fabricate readings, measurements, dates, or claim details.\n"
}

SHA-256 of public snapshot: a24ae38cf8fd507ff81aad144994a0bfb7dc46635984de613484b5fcd5325555