magicplan

View saved version →

---
name: magicplan-adjuster-handoff
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.
compatibility: Requires the magicplan connector (MCP tools) for project and workspace data.
metadata:
  author: magicplan
  version: "1.0"
---

# magicplan Adjuster Handoff

Assemble a concise, factual package a restoration professional can hand to an insurance adjuster or
carrier representative. The tone is measured and neutral throughout — present conditions observed and
what the documentation shows, not advocacy for scope. A clean, honest handoff builds carrier trust; an
overreaching one invites pushback.

This skill reads from magicplan only and does not change workspace data. It documents the project state;
it does not decide coverage — that is the carrier's and adjuster's call.

## Step 1 — Load the built-in playbook

If restoration resources are available, read the **`restoration://playbooks/adjuster-handoff`** resource
and follow its review sequence — it is the authoritative structure for this task. The
`restoration://playbooks/fnol-to-scope` playbook is a useful companion when the handoff also needs to
frame first-scope reasoning. Combine the playbook's sequence with the template and best practices in
`references/handoff-guide.md`. If resources are not available, use the reference file alone.

## Step 2 — Ask about carrier-specific requirements

Before building, ask the user whether they have **carrier-specific requirements** for this handoff, for
example:

- The **carrier / program** and any house format or portal it must fit.
- **Required forms or attachments** the carrier expects (specific documentation, authorizations).
- **Reference numbers** — claim number, adjuster name/contact, policyholder details.
- Any **house rules** on tone, itemization, or what to include/exclude.

If they have a spec, follow it. If not, tell them you'll use standard best practices from the playbook
and reference file, and proceed. Also ask once for the **company name and contact details** for the
header — never assume branding.

## Step 3 — Gather the project documentation

Following the playbook sequence, read:

- `get_project_snapshot` — property type, floors, affected rooms, estimates, `plan_id`, `cloud_url`.
- `get_plan_statistics` — approximate square footage and per-room measurements.
- `get_project_plan` — affected-area annotations, loss type/category/class if set, equipment placed.
- `get_plan_forms` — completed workspace custom forms.
- `get_moisture_readings` — instrument drying history (empty series = a gap to name).
- `list_project_photos` — photo evidence (counts, captions, URLs); page through `page_info`.
- `list_project_files` — reports, third-party assessments, other documents.
- `list_estimates` / `get_estimate` — estimate posture and, if needed, coverage of line items.

## Step 4 — Build the package

Produce the handoff using the structure in `references/handoff-guide.md`: project & affected-area
summary, documentation inventory (forms, photos, files, readings — with gaps named), estimate posture
(what it covers, no opinion on whether it is high or low), and a clean list of open questions sorted into
field / adjuster / customer / third-party items, each phrased as a neutral question rather than 

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: magicplan-drying-report
description: >-
  Build a professional structural drying / moisture-progress report from a magicplan project's moisture
  instruments and atmospheric readings, aligned to IICRC S500 principles. Use this whenever someone wants
  to review, document, or report drying progress on a water-damage job: "generate a drying report",
  "how's the dry-out going on the Barbaro job", "pull the moisture readings into a report", "is it dry
  yet", "daily drying log", "psychrometric report", "show me the drying progress", "document the drying
  for the file", or "S500 drying documentation". Trigger it even when the person just asks whether a job
  has reached dry standard or wants the moisture history turned into something shareable.
compatibility: Requires the magicplan connector (MCP tools) for project and workspace data.
metadata:
  author: magicplan
  version: "1.0"
---

# magicplan Drying Report

Turn the moisture and atmospheric readings captured in a magicplan project into a clear structural
drying report that shows, room by room and instrument by instrument, where each material started, where
it is now, and whether it has reached a dry standard — evaluated against IICRC S500 drying principles.

This skill reads from magicplan only; it never changes workspace data. The report documents what the
readings show. State drying facts plainly, flag documentation gaps honestly, and leave restoration
method and coverage decisions to the professional and the carrier.

## Step 1 — Identify the project and pull the drying data

Find the project with `list_projects` (partial `name` match); disambiguate if several match. Then:

1. `get_project_snapshot` — project details, per-room documentation map, the `plan_id`, and the
   `cloud_url` deep link.
2. `get_moisture_readings` (needs the `plan_id`) — the core input. Returns one entry per instrument,
   localized to its floor and room, with a dated series: moisture content, material and relative scale,
   air and surface temperature, relative humidity, and humidity ratio. **Instruments placed but not yet
   read appear with an empty readings list** — keep them in the report as gaps.
3. `get_plan_forms` (needs the `plan_id`) — some crews log daily atmospheric/psychrometric readings
   (outside, unaffected/reference, affected, dehumidifier outlet) in workspace custom forms rather than
   on instruments. Check here and fold any drying-relevant forms into the report.
4. `get_plan_statistics` and `get_project_plan` — room dimensions, volumes, and the drying equipment
   placed (air movers, dehumidifiers, cavity dryers) plus affected-area notes, for context and equipment
   adequacy commentary.

## Step 2 — Understand the drying picture

Read `references/drying-standards.md` for how to interpret readings against S500 before you write. In
brief, for each material/instrument establish, from the data:

- The **dry standard / goal** — the target moisture content, ideally from a reference (unaffected
  material of the same type). If none is recorded, say the dry standard is undocumented rather than
  inventing one.
- The **initial reading** and the **most recent reading**, the **trend** across the dated series, and
  whether the material has **reached dry standard**, is **trending down**, or is **stalled/rising**.
- **Atmospheric conditions** — whether the affected-area humidity ratio (grains per pound) is being
  pulled below the reference/outside air, i.e. whether the drying system is actually removing moisture.
- **Equipment adequacy** — a sanity check of air movers and dehumidifier capacity against the affected
  area and volume (see the reference file for the S500 rules of thumb). Present this as a check, not a
  verdict.

## Step 3 — Handle the gaps explicitly

Drying files are frequently incomplete, and a report that hides that is worse than useless if a carrier
reviews it. Call out, as plain facts:

- Instruments **placed but never read** — no baseline, no progression.
- *

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: magicplan-estimate-status
description: >-
  Surface the status of estimates in a magicplan project or across the workspace at a glance — which
  estimates exist, their status (draft, sent, approved, etc.), what they cover, and what's outstanding —
  without opening each one by hand. Use this whenever someone wants an estimate overview or to find work
  that needs action: "what's the status of the estimates on this job", "which estimates are still in
  draft", "show me all open estimates", "what estimates are waiting on approval", "estimate status across
  my projects", "which projects don't have an estimate yet", or "what needs to go out". Trigger it
  whenever the focus is estimate status, outstanding estimates, or estimate coverage rather than building
  a new estimate.
compatibility: Requires the magicplan connector (MCP tools) for project and workspace data.
metadata:
  author: magicplan
  version: "1.0"
---

# magicplan Estimate Status

Give a fast, honest read on where estimates stand — for one project or across the workspace — so the user
can see what's drafted, what's out, what's approved, and what still needs attention, without opening each
estimate manually.

This skill reads from magicplan only and never changes workspace data.

## Step 1 — Set the scope

Decide whether the user means **one project** or **across the workspace**, and ask if it's unclear. A
single project is one snapshot; a workspace sweep is many calls, so confirm before a broad run.

## Step 2a — Single project

1. `list_projects` (partial `name` match) to find it; disambiguate if needed.
2. `get_project_snapshot` — returns the project's estimates with their status, newest first, plus the
   `cloud_url`. This alone answers most status questions.
3. `get_estimate` — only for the estimates where the user needs the detail: line items, totals, and what
   the estimate covers. Use this to spot outstanding items (see Step 3).

## Step 2b — Across the workspace

1. `get_workspace` to confirm context, then `list_projects`, **paging through all** results via
   `page_info`. Apply `name`/`email`/`sort` filters if the user narrowed the scope.
2. For each project in scope, read its estimates from `get_project_snapshot` (and `list_estimates` /
   `get_estimate` where more detail is needed). This is one-or-more calls per project — **tell the user
   how many projects you'll sweep, cap it sensibly, and don't silently truncate.** If they only care about
   a status (e.g. "all drafts"), you can often answer from the snapshot's estimate list without pulling
   every estimate's line items.

## Step 3 — Read status and what's outstanding

For each estimate, capture its **status** and, where the user needs it, what it **covers** and what's
**outstanding**. Outstanding / needs-attention signals include:

- Estimates still in **draft** (not sent) — especially on older projects.
- Estimates **sent** and awaiting a response for a while.
- Projects with **affected rooms but no estimate at all**.
- An estimate that **doesn't cover every affected room** (compare its coverage against the affected rooms
  from `get_project_snapshot` / `get_project_plan`).
- Rejected or superseded estimates needing a revision.

Sort the output by attention needed, so the most actionable items are at the top.

## Step 4 — Deliver

Default to a compact **status table** — project, estimate, status, coverage, and a short "next action" —
sorted by what needs attention first, with a one-line headline (e.g. "3 drafts unsent, 2 projects with no
estimate"). Offer a polished file or a quick in-chat readout. For each item that needs action, include the
project `cloud_url` so the user can jump straight to it, or hand it to the mitigation-scope skill to build
a missing estimate's scope.

## Principles

- Answer at the cheapest level that's accurate — the snapshot's estimate list before per-estimate detail.
- Page through everything before making "all"/"none"/count claims across the workspace.
- Be e

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: magicplan-mitigation-scope
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.
compatibility: Requires the magicplan connector (MCP tools) for project and workspace data.
metadata:
  author: magicplan
  version: "1.0"
---

# magicplan Mitigation Scope of Work

Turn a magicplan water-damage project into a clean, defensible mitigation scope — the SKUs and quantities
an estimator needs, each tied to its basis in the plan — by reading the documentation, asking a short set
of clarifying questions, and mapping S500-driven quantities onto the user's own price list. The output
carries **no prices**: SKUs, descriptions, units, quantities, and the basis for each. Pricing, overhead,
tax, and minimums stay with the estimator and their price list.

This skill reads from magicplan only and never changes workspace data. It documents and reasons from what
the plan shows; where the plan is silent it asks or states an assumption. It does not decide coverage.

## Step 0 — Get the price list (required)

This skill needs the user's price list so the scope speaks in their SKUs and units. **Ask for it before
scoping.** Explain what's useful:

- Their price list export — Xactimate / Verisk structure, or any in-house list — as a file (CSV, Excel,
  or PDF) placed in the working folder or attached.
- It should include, at minimum, **item codes/SKUs, descriptions, and units**. Category/selector metadata
  helps matching. **Prices are not needed and will not be used** — reassure the user on this; the scope is
  quantities only.

Load and index the price list (see `references/scope-method.md`, "Working with the price list"). If the
user has no price list handy, offer to proceed with a **generic S500 line-item structure** they can map
to their list later, and make clear the codes will be generic placeholders.

## Step 1 — Load the project

Find it with `list_projects` (partial `name` match); disambiguate if several match. Then read it fully —
this scope is only as good as the reading behind it:

- `get_project_snapshot` — affected rooms, per-room documentation, `plan_id`, `cloud_url`.
- `get_project_plan` — claim attributes (carrier, claim #, **category/class of loss**), affected-area
  annotations **and their notes** (cause, migration path, material notes), and every placed object
  including equipment (air movers, dehumidifiers, cavity dryers, meters).
- `get_plan_statistics` (needs `plan_id`) — floor/wall areas, ceiling heights, volumes, perimeters,
  openings, per room. These are your quantity inputs.
- `get_moisture_readings` (needs `plan_id`) — instruments and readings (empty series = a gap).
- `list_project_photos` — captions/URLs that confirm materials and conditions; page through `page_info`.
- `get_plan_forms` (needs `plan_id`) — intake/room condition forms with extra field detail.

## Step 2 — Report what's documented and what's missing

Before asking questions, give the user a short two-part readout, exactly in this spirit:

- **Documented:** per affected room — dimensions, ceiling height, affected floor/wall area, migration
  path, materials noted, equipment placed, meters placed.
- **Gaps:** e.g. no claim attributes (carrier/claim #/category/class), zero

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: magicplan-photo-review
description: >-
  Audit the photo documentation of a magicplan restoration project room by room — matching each photo to
  the plan object it documents (room, affected area, or instrument) and reporting where coverage is
  complete and where it is thin. Use this whenever someone wants to check or verify photo documentation:
  "review the photos on this job", "which rooms are missing photos", "is our photo documentation
  complete", "photo audit before I send this to the adjuster", "do we have before photos of the affected
  areas", "check the photo coverage per room", or "are the moisture meters photographed". Trigger it even
  when the person just asks whether a project is well-documented photographically or wants a
  per-room coverage checklist.
compatibility: Requires the magicplan connector (MCP tools) for project and workspace data.
metadata:
  author: magicplan
  version: "1.0"
---

# magicplan Photo Documentation Review

Check, room by room, whether a magicplan project's photos actually document what a restoration file needs
them to — overview, source, affected materials, equipment, and readings — by matching each photo to the
plan object it is attached to, and reporting coverage and gaps clearly.

This skill reads from magicplan only. It reports what is documented; it does not judge the restoration
work itself.

## Step 1 — Identify the project

Find it with `list_projects` (partial `name` match); disambiguate if several match.

## Step 2 — Build the room/object map, then the photo map

1. `get_project_snapshot` — per-room documentation map with photo counts and affected flags, plus the
   `plan_id` and `cloud_url`. This gives you the quick shape; the per-room counts cover photos attached
   to the room or an object inside it.
2. `get_project_plan` — every floor, room, and object with its `uid`, including affected-area
   annotations and placed equipment (air movers, dehumidifiers, cavity dryers, moisture meters). This is
   what photos should be documenting.
3. `list_project_photos` — page through **all** pages via `page_info`. Each photo carries a `caption`
   (often the only description of what it shows), a fetchable `url`, and `attached_to_uid`.

Match each photo's `attached_to_uid` to the `uid` of a room or an object from the plan. Note:

- A photo attached to a room `uid` documents that room generally.
- A photo attached to an object `uid` (affected area, instrument, appliance) documents that object.
- Photos attached at **floor or plan level** are not room-specific; count them separately, do not credit
  them to a room's coverage.

## Step 3 — Score coverage against the checklist

For each **affected** room (and each room the user cares about), check the documentation checklist below.
Affected rooms carry the weight of the file, so judge them hardest; unaffected rooms need far less.

Well-documented affected room — expect photos covering:

- **Overview** — a wide shot establishing the room and its condition.
- **Source / cause** — the origin or entry point of the water where visible.
- **Affected materials** — flooring, walls, ceiling, trim showing the damage; ideally matching the
  affected-area annotations on the plan.
- **Moisture readings in progress** — a meter on the material showing a reading, tying to the moisture
  instruments placed.
- **Equipment placed** — air movers / dehumidifiers / cavity dryers in position, matching the equipment
  objects on the plan.
- **Contents** — affected contents, and pack-out/manipulation if relevant.

Flag these gap patterns plainly:

- A room marked **affected with 0 photos** — damage asserted, not shown (the highest-priority gap).
- **Equipment placed on the plan but not photographed** — no visual proof it was deployed.
- **Moisture instruments placed but no reading photos** — pairs with a drying-documentation gap.
- **Affected-area annotations with no matching photo** of that material.
- Rooms with photos but **no captions**, where wha

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: magicplan-project-summary
description: >-
  Produce a detailed, purpose-driven summary of a magicplan restoration project — rooms, affected
  areas, measurements, and documentation status (photos, moisture readings, forms, estimates, files),
  including the gaps. Use this whenever someone wants to understand, summarize, brief, or catch up on a
  magicplan project: "summarize project X", "what's the situation on the Barbaro loss", "brief me before
  my client call", "give me an overview of this job", "catch me up on unit 6188302", "write a status
  email about this project", or "prep me for the adjuster". Trigger it even when the person only names a
  project and asks "what's going on here" — the whole point is to turn raw magicplan documentation into a
  summary shaped for how they are about to use it (client call, email, internal brief, or quick status).
compatibility: Requires the magicplan connector (MCP tools) for project and workspace data.
metadata:
  author: magicplan
  version: "1.0"
---

# magicplan Project Summary

Turn the documentation captured in a magicplan project into a clear summary shaped for how the user is
about to use it. A summary for a client phone call sounds nothing like an insurer-facing status email,
so the work is two parts: first read the project completely and honestly, then package it for the
purpose.

This skill only reads from magicplan; it never changes workspace data. Report what the documentation
shows, keep observed facts separate from your own inferences, and leave coverage decisions to the
carrier and adjuster.

## Step 1 — Identify the project

If the user named a project, find it with `list_projects` (use the `name` filter — partial matches
work). If the name is vague or returns several hits, show the candidates (name, address, last modified)
and ask which one before going further. If they gave no project, ask for a name, address, or assignee
email rather than guessing.

## Step 2 — Read the project completely

Always start with `get_project_snapshot` — it returns project details, a per-room documentation map
(whether each room is affected, its photo count, and how many moisture instruments were placed), the
`plan_id`, the estimates, and a `cloud_url` deep link to the project. Then fill in the detail with the
other tools as the purpose requires:

- `get_project_plan` — claim attributes (carrier, claim number, category/class of loss), and per floor
  and room the field values, placed objects, equipment, and **affected-area annotations with their
  notes**. This is where the actual damage description lives.
- `get_plan_statistics` (needs the `plan_id`) — floor and wall areas, ceiling heights, volumes, door/
  window/furniture counts, per room.
- `get_moisture_readings` (needs the `plan_id`) — drying history per instrument. An instrument with an
  empty readings list was placed but never read: a drying-documentation gap, not something to omit.
- `list_project_photos` — photo evidence, with captions and the `attached_to_uid` linking each photo to
  a plan object. Page through `page_info` if there are many.
- `get_plan_forms` (needs the `plan_id`) — completed workspace custom forms (intake, room condition).
- `list_project_files` — reports, third-party assessments, and other documents already on file.
- `list_estimates` / `get_estimate` — estimate posture and, if needed, line items.

For a quick status you may not need every tool; for a full pre-call or pre-handoff brief, read them all.

## Step 3 — Assess documentation status and gaps

The documentation status is often the most useful part of the summary, so make it explicit. For each
affected room, check whether it has photos, moisture readings (if instruments were placed), and a
condition form. Flag these patterns plainly:

- A room marked **affected** with **0 photos** — the damage is asserted but not shown.
- Moisture **instruments placed but with no readings** — no drying evidence.
- **Empty claim attributes** — no carrier, c

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: magicplan-workspace-report
description: >-
  Report across all projects in a magicplan workspace — list, filter, search, and roll up statistics
  (recent activity, projects by assignee, by time period, by documentation or estimate posture) and
  recommend the most useful cut based on what the person is after. Use this whenever someone wants a
  workspace- or portfolio-level view rather than one project: "how many projects did we open last month",
  "list all my active jobs", "show me everything assigned to Maria", "which projects haven't been touched
  in weeks", "give me a workspace overview", "projects by loss type", "portfolio dashboard", or "what's
  in the workspace". Trigger it whenever the scope is many projects at once, or when the person asks for
  counts, trends, or a filtered project list across the workspace.
compatibility: Requires the magicplan connector (MCP tools) for project and workspace data.
metadata:
  author: magicplan
  version: "1.0"
---

# magicplan Workspace Report

Give the user a workspace-level view of their projects — filtered, searched, and rolled up the way that
answers their actual question. When the ask is vague ("give me an overview"), propose the cuts that are
most useful and let them pick, rather than dumping an undifferentiated list.

This skill reads from magicplan only and never changes workspace data.

## Step 1 — Orient

Call `get_workspace` to confirm which workspace you're reporting on. If the user's request is specific
(e.g. "projects opened last month"), go straight to Step 3. If it's open-ended, do Step 2 first.

## Step 2 — Recommend a cut

When the user hasn't pinned down what they want, suggest the reports that fit their situation and let them
choose (single or multiple). Common, high-value cuts:

- **Recent activity** — projects created or modified in a window (last week/month/quarter).
- **By assignee** — projects grouped by the user they're assigned to (`email` filter).
- **Stalled / needs attention** — projects not modified in N days.
- **New intake** — projects created recently, oldest-first, to work a queue.
- **Documentation posture** — across a subset, which projects have photos / moisture readings / estimates
  vs. gaps (deeper — see the note in Step 3 about cost).
- **Loss-type or location breakdown** — grouped by address/region or by loss type where recorded.
- **Name/keyword search** — everything matching a term.

Tailor the suggestions to any hint in their prompt (a name, a person, a timeframe).

## Step 3 — Pull the data

Use `list_projects` with the filters and paging that fit the cut:

- `name` — partial/exact name search.
- `email` — projects assigned to a user.
- `sort` — `Projects.name`, `Projects.user_created`, or `Projects.user_modified`; with `direction`
  `asc`/`desc`.
- `page` — **page through all results** using `page_info` so counts and lists are complete, not just
  page 1. Report `total_count` for any count question.

Each project row carries id, name, address, assignee, and created/modified timestamps — enough for
listing, grouping, time-window, and assignee reports directly.

**Deeper posture reports cost more calls.** Documentation/estimate posture is not in the project list; it
requires `get_project_snapshot` per project. If the user wants that across many projects, confirm the
scope first, cap it to a sensible subset (e.g. the filtered list or a stated limit), tell them how many
you'll inspect, and never silently truncate — if you cap, say what was left out.

## Step 4 — Deliver

Match the format to the cut and size:

- A **filtered list** → a clean table (name, address, assignee, created, modified), sorted as asked.
- **Counts / trends** → the headline number(s) plus a short table or simple chart (e.g. projects per
  month), with the total and the window stated.
- **Grouped** (by assignee, loss type, region) → grouped tables with subtotals.
- A **dashboard** → a self-contained one-pager (HTML prints well) with the key counts, a recenc

Preview of the first 4,000 characters. Read full instructions →