← magicplanCONTENT HISTORYWHAT CHANGED · RULE-BASED ANALYSIS
Update to magicplan
Snapshot Sep 30, 2026 · 23:00 UTC · version 1.0.2
Collection source: not recorded for this historical snapshot.
First saved snapshot
No earlier snapshot is available to establish a change.
Compare saved observations
Download comparison JSONFull technical diff · 0 changed fields
Full snapshot data
{
"description": "Build a defensible water-damage mitigation scope of work from a magicplan project and the user's own price list — deriving line items (SKUs and quantities, no prices) through a short guided conversation, aligned to IICRC S500. Use this whenever someone wants to turn a magicplan loss into an estimate scope: \"build a mitigation scope for this job\", \"derive the line items for the Stanton Close water damage\", \"scope this loss against my Xactimate price list\", \"what quantities should I estimate here\", \"create a scope of work from the plan\", \"help me estimate the drying for this project\", or \"turn this project into an itemized scope\". Trigger it whenever the goal is an itemized mitigation scope or estimate from magicplan documentation — it will ask for the price list and clarify the situation before scoping.",
"included_files": [
{
"relative_path": "references/scope-method.md",
"size_in_bytes": 10322
}
],
"name": "magicplan-mitigation-scope",
"skill_md_contents": "---\nname: magicplan-mitigation-scope\ndescription: >-\n Build a defensible water-damage mitigation scope of work from a magicplan project and the user's own\n price list — deriving line items (SKUs and quantities, no prices) through a short guided conversation,\n aligned to IICRC S500. Use this whenever someone wants to turn a magicplan loss into an estimate scope:\n \"build a mitigation scope for this job\", \"derive the line items for the Stanton Close water damage\",\n \"scope this loss against my Xactimate price list\", \"what quantities should I estimate here\", \"create a\n scope of work from the plan\", \"help me estimate the drying for this project\", or \"turn this project\n into an itemized scope\". Trigger it whenever the goal is an itemized mitigation scope or estimate from\n magicplan documentation — it will ask for the price list and clarify the situation before scoping.\ncompatibility: Requires the magicplan connector (MCP tools) for project and workspace data.\nmetadata:\n author: magicplan\n version: \"1.0\"\n---\n\n# magicplan Mitigation Scope of Work\n\nTurn a magicplan water-damage project into a clean, defensible mitigation scope — the SKUs and quantities\nan estimator needs, each tied to its basis in the plan — by reading the documentation, asking a short set\nof clarifying questions, and mapping S500-driven quantities onto the user's own price list. The output\ncarries **no prices**: SKUs, descriptions, units, quantities, and the basis for each. Pricing, overhead,\ntax, and minimums stay with the estimator and their price list.\n\nThis skill reads from magicplan only and never changes workspace data. It documents and reasons from what\nthe plan shows; where the plan is silent it asks or states an assumption. It does not decide coverage.\n\n## Step 0 — Get the price list (required)\n\nThis skill needs the user's price list so the scope speaks in their SKUs and units. **Ask for it before\nscoping.** Explain what's useful:\n\n- Their price list export — Xactimate / Verisk structure, or any in-house list — as a file (CSV, Excel,\n or PDF) placed in the working folder or attached.\n- It should include, at minimum, **item codes/SKUs, descriptions, and units**. Category/selector metadata\n helps matching. **Prices are not needed and will not be used** — reassure the user on this; the scope is\n quantities only.\n\nLoad and index the price list (see `references/scope-method.md`, \"Working with the price list\"). If the\nuser has no price list handy, offer to proceed with a **generic S500 line-item structure** they can map\nto their list later, and make clear the codes will be generic placeholders.\n\n## Step 1 — Load the project\n\nFind it with `list_projects` (partial `name` match); disambiguate if several match. Then read it fully —\nthis scope is only as good as the reading behind it:\n\n- `get_project_snapshot` — affected rooms, per-room documentation, `plan_id`, `cloud_url`.\n- `get_project_plan` — claim attributes (carrier, claim #, **category/class of loss**), affected-area\n annotations **and their notes** (cause, migration path, material notes), and every placed object\n including equipment (air movers, dehumidifiers, cavity dryers, meters).\n- `get_plan_statistics` (needs `plan_id`) — floor/wall areas, ceiling heights, volumes, perimeters,\n openings, per room. These are your quantity inputs.\n- `get_moisture_readings` (needs `plan_id`) — instruments and readings (empty series = a gap).\n- `list_project_photos` — captions/URLs that confirm materials and conditions; page through `page_info`.\n- `get_plan_forms` (needs `plan_id`) — intake/room condition forms with extra field detail.\n\n## Step 2 — Report what's documented and what's missing\n\nBefore asking questions, give the user a short two-part readout, exactly in this spirit:\n\n- **Documented:** per affected room — dimensions, ceiling height, affected floor/wall area, migration\n path, materials noted, equipment placed, meters placed.\n- **Gaps:** e.g. no claim attributes (carrier/claim #/category/class), zero moisture readings, no air\n movers placed, rooms on the loss floor not marked affected.\n\nThis mirrors how a good estimator orients before scoping, and it tells the user what the clarifying\nquestions are about to resolve.\n\n## Step 3 — Ask the clarifying questions\n\nThe plan rarely records everything a scope needs, so ask a focused set of questions and let the user\nsteer. Present them as clear multiple-choice where possible (with an option to answer freely). Ask only\nthe ones the data leaves open; skip any the plan already answers. The core set:\n\n1. **Rooms in scope** — which rooms the scope should cover (e.g. affected rooms only / whole loss floor /\n affected rooms + access route like a hall).\n2. **Approach — dry in place vs. remove** — dry in place, detach & reset, or tear out; and how far (e.g.\n remove sagging ceiling + dry walls / flood-cut walls / dry in place throughout / let the moisture data\n decide).\n3. **Category & class of loss** — if not set on the plan, which to scope against (Cat 1/2/3, Class 1–4).\n Offer \"you tell me from the photos\" and reason from the evidence if they prefer.\n4. **Floor & wall build-up** — the actual assembly where the plan/meters don't say (e.g. carpet over\n slab / laminate-engineered over concrete / bare tiled concrete / check the photos). This drives\n whether floors can dry in place or must come up.\n5. **Air movers / equipment** — when equipment is under-placed on the plan, whether to calculate per S500,\n document only what's placed, or calculate and list separately.\n6. **Equipment & monitoring duration** — number of drying days and monitoring visits to scope (e.g.\n 3 days + 3 visits / 5 days + 5 visits / per-day lines at qty 1 / \"I'll give you the dates\").\n7. **Units** — the plan may be metric while the price list is imperial (SF/LF/CF). Convert to imperial,\n show metric with imperial in brackets, or keep metric.\n8. **Deliverable** — how they want it handed over (see Step 6).\n\n`references/scope-method.md` explains how each answer changes the scope.\n\n## Step 4 — Derive quantities\n\nCompute quantities from the plan statistics and the answers, following the S500 logic and formulas in\n`references/scope-method.md`. Every line's quantity must have a traceable **basis** (e.g. \"Bedroom —\nprimary, affected floor area\", \"3 units × 3 days\", \"400 mm centres along affected wall bases\"). Where a\nquantity depends on a choice the data can't settle (annotated affected area vs. room-wide), compute the\nprimary figure and offer the alternative in a note, as the reference shows.\n\n## Step 5 — Map to the price list\n\nMatch each derived line to the user's price list by description and unit, and carry the user's **exact\nSKU/code and unit**. Keep families together (emergency/documentation, extraction, access/protection/\ncontainment, tear-out & detach/reset, drying equipment, specialty drying, monitoring, PPE, and any\ncategory-specific items like antimicrobial or air scrubbing). If a needed item has no clear match, list it\nwith a clearly-marked placeholder code and flag it for the user to map. Never inject prices.\n\n## Step 6 — Deliver\n\nProduce the scope in the format the user chose. Default to a polished pair: a **line-item sheet**\n(Excel/CSV: SKU, description, unit, quantity, basis — ready to import or paste into the price list) **plus\na short scope document** (the basis of scope, measured quantities, line items by phase, alternatives, and\nopen issues) using the template in `references/scope-method.md`. Offer alternatives: sheet only,\ndocument only (markdown/HTML), or sheet + assumptions memo.\n\nAlways include an **Open issues** section listing the gaps and assumptions that affect the scope (missing\nreadings, unverified build-up, category assumed, ceiling stability, equipment calculated vs. documented).\nThis is what makes the scope defensible if a carrier reviews it.\n\n### Report-gap recommendation\n\nIf the loss floor or affected areas are too thin to scope responsibly (e.g. no affected-area annotations,\nno measurements), tell the user and give them the project `cloud_url` to complete the documentation in\nmagicplan, then offer to build the scope once it's there.\n\n## Principles\n\n- **No prices.** Quantities, SKUs, and basis only. Say so on the deliverable.\n- Every quantity is traceable to a measurement, an annotation, or a stated assumption.\n- Keep documented facts, S500 calculations, and user instructions distinguishable in the basis notes.\n- State unit conversions; never silently mix metric and imperial.\n- Reason from the photos and notes when asked, but label anything inferred rather than measured.\n"
}SHA-256 of public snapshot: be3d17d1d1a944f0aadf8055228f38247a29866348e610931f1dc3d52f356bcb