← 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": "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).",
"included_files": [
{
"relative_path": "references/output-modes.md",
"size_in_bytes": 3698
}
],
"name": "magicplan-project-summary",
"skill_md_contents": "---\nname: magicplan-project-summary\ndescription: >-\n Produce a detailed, purpose-driven summary of a magicplan restoration project — rooms, affected\n areas, measurements, and documentation status (photos, moisture readings, forms, estimates, files),\n including the gaps. Use this whenever someone wants to understand, summarize, brief, or catch up on a\n magicplan project: \"summarize project X\", \"what's the situation on the Barbaro loss\", \"brief me before\n my client call\", \"give me an overview of this job\", \"catch me up on unit 6188302\", \"write a status\n email about this project\", or \"prep me for the adjuster\". Trigger it even when the person only names a\n project and asks \"what's going on here\" — the whole point is to turn raw magicplan documentation into a\n summary shaped for how they are about to use it (client call, email, internal brief, or quick status).\ncompatibility: Requires the magicplan connector (MCP tools) for project and workspace data.\nmetadata:\n author: magicplan\n version: \"1.0\"\n---\n\n# magicplan Project Summary\n\nTurn the documentation captured in a magicplan project into a clear summary shaped for how the user is\nabout to use it. A summary for a client phone call sounds nothing like an insurer-facing status email,\nso the work is two parts: first read the project completely and honestly, then package it for the\npurpose.\n\nThis skill only reads from magicplan; it never changes workspace data. Report what the documentation\nshows, keep observed facts separate from your own inferences, and leave coverage decisions to the\ncarrier and adjuster.\n\n## Step 1 — Identify the project\n\nIf the user named a project, find it with `list_projects` (use the `name` filter — partial matches\nwork). If the name is vague or returns several hits, show the candidates (name, address, last modified)\nand ask which one before going further. If they gave no project, ask for a name, address, or assignee\nemail rather than guessing.\n\n## Step 2 — Read the project completely\n\nAlways start with `get_project_snapshot` — it returns project details, a per-room documentation map\n(whether each room is affected, its photo count, and how many moisture instruments were placed), the\n`plan_id`, the estimates, and a `cloud_url` deep link to the project. Then fill in the detail with the\nother tools as the purpose requires:\n\n- `get_project_plan` — claim attributes (carrier, claim number, category/class of loss), and per floor\n and room the field values, placed objects, equipment, and **affected-area annotations with their\n notes**. This is where the actual damage description lives.\n- `get_plan_statistics` (needs the `plan_id`) — floor and wall areas, ceiling heights, volumes, door/\n window/furniture counts, per room.\n- `get_moisture_readings` (needs the `plan_id`) — drying history per instrument. An instrument with an\n empty readings list was placed but never read: a drying-documentation gap, not something to omit.\n- `list_project_photos` — photo evidence, with captions and the `attached_to_uid` linking each photo to\n a plan object. Page through `page_info` if there are many.\n- `get_plan_forms` (needs the `plan_id`) — completed workspace custom forms (intake, room condition).\n- `list_project_files` — reports, third-party assessments, and other documents already on file.\n- `list_estimates` / `get_estimate` — estimate posture and, if needed, line items.\n\nFor a quick status you may not need every tool; for a full pre-call or pre-handoff brief, read them all.\n\n## Step 3 — Assess documentation status and gaps\n\nThe documentation status is often the most useful part of the summary, so make it explicit. For each\naffected room, check whether it has photos, moisture readings (if instruments were placed), and a\ncondition form. Flag these patterns plainly:\n\n- A room marked **affected** with **0 photos** — the damage is asserted but not shown.\n- Moisture **instruments placed but with no readings** — no drying evidence.\n- **Empty claim attributes** — no carrier, claim number, category, or class of loss set.\n- **No estimate** created, or an estimate that does not cover an affected room.\n- Rooms present in the plan but never marked affected and never photographed — condition unrecorded\n rather than confirmed clear.\n\nName gaps as facts (\"no moisture readings are on file\"), not as failures or accusations.\n\n## Step 4 — Ask what the summary is for\n\nBefore writing the summary, ask the user the purpose, because it changes the tone, length, and format.\nOffer these modes (single choice), and let them describe something else:\n\n- **Client call prep** — a talking-points brief you can glance at while on the phone.\n- **Client email / update** — a ready-to-send written message with a subject line.\n- **Internal team brief** — an operational catch-up for a colleague or crew.\n- **Adjuster / carrier status** — a neutral, factual status suitable for the insurer.\n- **Quick status** — a short in-chat readout, no file.\n\nRead `references/output-modes.md` for the structure of each mode. Match the depth of your Step 2 reading\nto the mode they choose.\n\nFor any outward-facing document (client email, adjuster status, or a client-call leave-behind), ask once\nfor the **company name and contact details** to put in the header — these skills are used by many\nrestoration companies, so never assume a brand. Keep the output otherwise neutral.\n\n## Step 5 — Deliver\n\nUnless they chose a quick in-chat status, produce a polished file in the fitting format (a clean written\ndocument for emails and briefs; a scannable one-pager for call prep) and hand it over. Keep the\nin-chat message to a one-line summary plus any critical gaps they should know before they use it.\n\n### Report-gap recommendation\n\nmagicplan can generate formal reports and estimates that this skill cannot create for the user. When the\nsummary would be stronger with something that does not yet exist — no estimate on file, no formal report\ndocument, thin photo coverage — tell the user and give them the project's `cloud_url` so they can\ngenerate or capture it in magicplan, then offer to fold the result into the summary once it exists. For\nexample: \"There's no estimate on this project yet. You can build one here: <cloud_url>. Once it's in,\nI can add its totals and status to this summary.\"\n\n## Principles\n\n- Separate **documented facts** (from forms, photos, readings, measurements) from **assumptions** you\n are making to fill gaps, and label the assumptions.\n- Never invent measurements, readings, dates, or claim details. If it is not in the data, say so.\n- Convert units to the audience's expectation when helpful, and state the conversion.\n- This skill works with whatever assistant and file tools are available; if a document-creation\n capability is present, use it for the polished deliverable, otherwise deliver clean formatted text.\n"
}SHA-256 of public snapshot: 599cc5c20ef86175de87fb30bc75a346c76b54b432e551a9e4e9bdddf6e68c7b