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 a demand.

Deliver a polished file (a clean written document; HTML or Word both print well) plus a one-line summary
in chat. Keep the document neutral and free of magicplan-specific jargon the adjuster would not use.

### Report-gap recommendation

A strong handoff often needs an estimate or report that lives in magicplan and cannot be generated here.
When the package would be materially stronger with something missing — no estimate on file, no formal
report, thin photo or moisture documentation — name the gap, give the user the project `cloud_url` so
they can generate or capture it in magicplan, and offer to fold it into the package once it exists.
Handing a carrier a package with visible, acknowledged gaps beats padding it with assumptions.

## Principles

- Neutral and factual. Present conditions observed; do not argue scope or coverage.
- Separate documented facts from assumptions; label assumptions.
- Name documentation gaps as neutral open items, not failures.
- Never fabricate readings, measurements, dates, or claim details.

Referenced files: 1

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.
- **No reference/dry-standard reading** for an affected material.
- **Missing daily readings** (gaps in the date series) — monitoring not continuous.
- **No initial reading** — the starting point is undocumented, so drying achieved cannot be proven.
- Affected rooms with **no instruments at all**.

## Step 4 — Produce the report

Build a polished, self-contained report using the exact structure in `references/drying-standards.md`
("Report structure"). Default to a clean, printable **HTML** document (single file, inline styles, no
external assets) because it renders anywhere and prints to PDF cleanly; offer Word or PDF instead if the
user prefers. Where charts help (a moisture-content-over-time line per room), include them; if charting
is not available, use clear per-day tables.

Ask once for the **company name and contact details** and the **client/property and claim reference** to
put in the header — these skills serve many restoration firms, so never assume branding. Keep the body
neutral and factual.

### Report-gap recommendation

If the drying data is too thin to support a defensible report — for example, every instrument has an
empty readings series — say so directly, give the user the project `cloud_url` so they can capture
readings in magicplan, and offer to generate the report once readings exist. A report that asserts
drying without readings is a liability, so never manufacture progression to fill the page.

## Principles

- Never invent readings, dates, dry standards, or trends. Missing data is reported as missing.
- Distinguish **documented readings** from **your interpretation** of them.
- Use the client's/region's unit expectation; state any conversion (e.g. metric plan → imperial report).
- Keep S500 references as supporting rationale, not as a compliance certification — you are documenting
  conditions, not certifying the job.

Referenced files: 1

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 explicit about any cap on a workspace sweep; never imply full coverage you didn't do.
- Report status as it is; don't opine on whether an estimate's amount is right.

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 moisture readings, no air
  movers placed, rooms on the loss floor not marked affected.

This mirrors how a good estimator orients before scoping, and it tells the user what the clarifying
questions are about to resolve.

## Step 3 — Ask the clarifying questions

The plan rarely records everything a scope needs, so ask a focused set of questions and let the user
steer. Present them as clear multiple-choice where possible (with an option to answer freely). Ask only
the ones the data leaves open; skip any the plan already answers. The core set:

1. **Rooms in scope** — which rooms the scope should cover (e.g. affected rooms only / whole loss floor /
   affected rooms + access route like a hall).
2. **Approach — dry in place vs. remove** — dry in place, detach & reset, or tear out; and how far (e.g.
   remove sagging ceiling + dry walls / flood-cut walls / dry in place throughout / let the moisture data
   decide).
3. **Category & class of loss** — if not set on the plan, which to scope against (Cat 1/2/3, Class 1–4).
   Offer "you tell me from the photos" and reason from the evidence if they prefer.
4. **Floor & wall build-up** — the actual assembly where the plan/meters don't say (e.g. carpet over
   slab / laminate-engineered over concrete / bare tiled concrete / check the photos). This drives
   whether floors can dry in place or must come up.
5. **Air movers / equipment** — when equipment is under-placed on the plan, whether to calculate per S500,
   document only what's placed, or calculate and list separately.
6. **Equipment & monitoring duration** — number of drying days and monitoring visits to scope (e.g.
   3 days + 3 visits / 5 days + 5 visits / per-day lines at qty 1 / "I'll give you the dates").
7. **Units** — the plan may be metric while the price list is imperial (SF/LF/CF). Convert to imperial,
   show metric with imperial in brackets, or keep metric.
8. **Deliverable** — how they want it handed over (see Step 6).

`references/scope-method.md` explains how each answer changes the scope.

## Step 4 — Derive quantities

Compute quantities from the plan statistics and the answers, following the S500 logic and formulas in
`references/scope-method.md`. Every line's quantity must have a traceable **basis** (e.g. "Bedroom —
primary, affected floor area", "3 units × 3 days", "400 mm centres along affected wall bases"). Where a
quantity depends on a choice the data can't settle (annotated affected area vs. room-wide), compute the
primary figure and offer the alternative in a note, as the reference shows.

## Step 5 — Map to the price list

Match each derived line to the user's price list by description and unit, and carry the user's **exact
SKU/code and unit**. Keep families together (emergency/documentation, extraction, access/protection/
containment, tear-out & detach/reset, drying equipment, specialty drying, monitoring, PPE, and any
category-specific items like antimicrobial or air scrubbing). If a needed item has no clear match, list it
with a clearly-marked placeholder code and flag it for the user to map. Never inject prices.

## Step 6 — Deliver

Produce the scope in the format the user chose. Default to a polished pair: a **line-item sheet**
(Excel/CSV: SKU, description, unit, quantity, basis — ready to import or paste into the price list) **plus
a short scope document** (the basis of scope, measured quantities, line items by phase, alternatives, and
open issues) using the template in `references/scope-method.md`. Offer alternatives: sheet only,
document only (markdown/HTML), or sheet + assumptions memo.

Always include an **Open issues** section listing the gaps and assumptions that affect the scope (missing
readings, unverified build-up, category assumed, ceiling stability, equipment calculated vs. documented).
This is what makes the scope defensible if a carrier reviews it.

### Report-gap recommendation

If the loss floor or affected areas are too thin to scope responsibly (e.g. no affected-area annotations,
no measurements), tell the user and give them the project `cloud_url` to complete the documentation in
magicplan, then offer to build the scope once it's there.

## Principles

- **No prices.** Quantities, SKUs, and basis only. Say so on the deliverable.
- Every quantity is traceable to a measurement, an annotation, or a stated assumption.
- Keep documented facts, S500 calculations, and user instructions distinguishable in the basis notes.
- State unit conversions; never silently mix metric and imperial.
- Reason from the photos and notes when asked, but label anything inferred rather than measured.

Referenced files: 1

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 what they show is ambiguous.

## Step 4 — Report

Produce a room-by-room coverage report. Default to a clean, scannable coverage matrix — rooms as rows,
checklist items as columns, marked present / missing / n-a — followed by a prioritized gap list and a
short "ready to send?" verdict. Offer it as a polished file (HTML matrix prints well) or a quick in-chat
readout; ask which. If the user wants to see the actual images, provide the photo `url`s grouped by room.

For an outward-facing file (e.g. attached to an adjuster package), ask once for the company name for the
header. Keep it neutral.

### Report-gap recommendation

Photos can only be captured in magicplan, not created here. When coverage is thin, give the user the
project `cloud_url` and a concrete shot list of what to capture on the next visit, then offer to re-run
the review once the photos are in.

## Principles

- Base coverage judgments on the actual photo→object matches and captions, not assumptions about what a
  crew "probably" shot.
- Distinguish "no photo on file" from "photo exists but unclear".
- Prioritize gaps by how much they matter to the file (affected rooms and equipment/readings first).

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, claim number, category, or class of loss set.
- **No estimate** created, or an estimate that does not cover an affected room.
- Rooms present in the plan but never marked affected and never photographed — condition unrecorded
  rather than confirmed clear.

Name gaps as facts ("no moisture readings are on file"), not as failures or accusations.

## Step 4 — Ask what the summary is for

Before writing the summary, ask the user the purpose, because it changes the tone, length, and format.
Offer these modes (single choice), and let them describe something else:

- **Client call prep** — a talking-points brief you can glance at while on the phone.
- **Client email / update** — a ready-to-send written message with a subject line.
- **Internal team brief** — an operational catch-up for a colleague or crew.
- **Adjuster / carrier status** — a neutral, factual status suitable for the insurer.
- **Quick status** — a short in-chat readout, no file.

Read `references/output-modes.md` for the structure of each mode. Match the depth of your Step 2 reading
to the mode they choose.

For any outward-facing document (client email, adjuster status, or a client-call leave-behind), ask once
for the **company name and contact details** to put in the header — these skills are used by many
restoration companies, so never assume a brand. Keep the output otherwise neutral.

## Step 5 — Deliver

Unless they chose a quick in-chat status, produce a polished file in the fitting format (a clean written
document for emails and briefs; a scannable one-pager for call prep) and hand it over. Keep the
in-chat message to a one-line summary plus any critical gaps they should know before they use it.

### Report-gap recommendation

magicplan can generate formal reports and estimates that this skill cannot create for the user. When the
summary would be stronger with something that does not yet exist — no estimate on file, no formal report
document, thin photo coverage — tell the user and give them the project's `cloud_url` so they can
generate or capture it in magicplan, then offer to fold the result into the summary once it exists. For
example: "There's no estimate on this project yet. You can build one here: <cloud_url>. Once it's in,
I can add its totals and status to this summary."

## Principles

- Separate **documented facts** (from forms, photos, readings, measurements) from **assumptions** you
  are making to fill gaps, and label the assumptions.
- Never invent measurements, readings, dates, or claim details. If it is not in the data, say so.
- Convert units to the audience's expectation when helpful, and state the conversion.
- This skill works with whatever assistant and file tools are available; if a document-creation
  capability is present, use it for the polished deliverable, otherwise deliver clean formatted text.

Referenced files: 1

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 recency
  breakdown, and the notable lists (stalled, new intake).

Ask whether they want a polished file or a quick in-chat readout. For any file, keep it neutral; ask once
for a company name only if it's going to be shared outside the team.

### Follow-through

Workspace reports are a launchpad. When a project surfaces that clearly needs action — a stalled job, one
with obvious documentation gaps, or one with no estimate — offer the next step and, where useful, its
`cloud_url` (from `get_project_snapshot`) so the user can jump straight in, or hand it to the
project-summary, drying-report, or estimate-status skill.

## Principles

- Page through everything before reporting counts; a partial page is a wrong count.
- State the filter, window, and total behind every number so the user can trust it.
- Be honest about cost/caps on deep posture reports; never imply full coverage you didn't do.