{"id":30730,"plugin_id":"plugin_asdk_app_6abc0713a40081919b055a6c32306e05","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-09T18:02:38.453Z","digest":"fc610c51919e5b4fed1f9edc214479ae8641a920914932240a2b048b3dc69408","against":null,"payload":{"description":"Build, furnish, edit, or assess native Planner5D homes from briefs, measurements, floor plans, furniture/model sources or interior/exterior reference pictures. Use for room and house design, furniture fit, showing the user's furniture in their interior, plan-to-AI-render workflows, and verified project handoff through the Planner 5D app or browser WebMCP. Keep observed, measured and proposed details distinct.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":493},{"relative_path":"references/fit-evidence.md","size_in_bytes":3773},{"relative_path":"references/floorplan-handoff.md","size_in_bytes":1870},{"relative_path":"references/picture-reconstruction.md","size_in_bytes":10617},{"relative_path":"references/room-construction.md","size_in_bytes":9091}],"name":"planner5d-webmcp","skill_md_contents":"---\nname: planner5d-webmcp\ndescription: Build, furnish, edit, or assess native Planner5D homes from briefs, measurements, floor plans, furniture/model sources or interior/exterior reference pictures. Use for room and house design, furniture fit, showing the user's furniture in their interior, plan-to-AI-render workflows, and verified project handoff through the Planner 5D app or browser WebMCP. Keep observed, measured and proposed details distinct.\nmetadata:\n  version: \"0.2.5\"\n---\n\n# Planner5D WebMCP\n\nCreate a project the person can continue editing normally. Optimize for a correct, usable result and bounded tool traffic.\n\n## Choose the input route\n\n- A floorplan drawing or a photograph of a floorplan can use recognition followed by source comparison. A real room/facade photo or a perspective render is not a floorplan: do not submit it to floorplan recognition.\n- For the person's specific furniture from a photo, product link or 3D file, use `planner5d-model-import` to reuse/import the actual item before placing or testing it. Preserve real product dimensions; a catalog lookalike needs an accepted approximation. A read-only dimensional question need not generate or place a model.\n- For interior/exterior pictures, mixed photo/plan references, or style recreation, read [picture-based reconstruction](references/picture-reconstruction.md) before geometry writes. Known dimensions control geometry; photographs control only the features they actually show. A precise hidden layout or scale cannot be recovered from one unmeasured photograph.\n- For a simple dimensioned layout, a measured coordinate brief, or an explicit manual request, native construction can be more direct than recognition. For scanned/complex plans use the [floorplan handoff](references/floorplan-handoff.md). Identify the intended model/pages in a brochure; do not recognize a whole mixed product page as one floorplan.\n\n## Connect and choose the workflow\n\nIn a Planner 5D MCP App, follow `planner5d-native-app`: discover with `get_planner5d_tools`, then wrap native reads/actions in `read_planner5d` or `change_planner5d` with the current panel/document IDs and a stable operation ID. Open the existing Planner app once and wait for the authenticated native tools. Navigation remains available across pages: `goToEditor`, `goToEditorProject`, and `goToSpaces`. For a new design from Spaces, use `projectCreateScene` and then `goToEditorProject` with the returned hash, or enter the editor with `goToEditor` and use `editorCreateScene`. After navigation, refresh the tool list and require `editorGetContext` to identify the intended editable project before scene writes. Missing editor tools in Spaces means the editor has not been opened; it is not a reason to replace the requested Planner project with a local PDF. If the host cannot discover tools after the app connects, report that exact integration blocker and preserve the brief.\n\n\n- Use the connected Planner 5D app tools or the requested browser tab and its public WebMCP tools. Read `getWebMcpGuide` once, then request help for only the relevant registered tool names, at most eight per call. The live schemas take precedence over examples here. Tool availability differs between Spaces, login, and the loaded editor.\n- In an opened editor, start with `editorGetContext({})`: bind the task to the exact project hash, floor, `canEdit`, and revision. Request `includeCamera:true` only when already in 3D and the camera is needed. Replace captured handles after navigation or a registration change. Do not bypass a missing tool with private editor state or an application API mutation.\n- Reuse the signed-in account. If login is required, use the normal login flow and the authorized mailbox for its current OTP. Do not adopt a staging identity, test card, or credential from a guide for production.\n- The separate `planner5d-floorplan-recheck` skill provides the full measured comparison/correction procedure when installed. If absent, follow the floorplan handoff reference without treating a finished recognition as proof of fidelity.\n- Recognition accepts supported 2D plan images/PDF/CAD, not arbitrary 3D scan files or segment lists. For measured scan geometry, derive a native room plan from the supplied coordinates and topology; use a supplied 2D plan for recognition only when that route matches the request.\n- For a new design, plan its shell and access before calling `projectCreateScene` from Spaces, or `editorCreateScene` from an editor. No starter project is necessary. Extend an existing scene with native room tools; do not replace its document merely to add a room.\n\n## Build editable rooms and walls\n\nRead [room construction](references/room-construction.md) when constructing, correcting **or assessing** room dimensions, walls or opening fit. Its measurement and fit checks also apply to read-only audits.\n\nUse native rooms with their visible perimeter walls for ordinary enclosed spaces. Reserve partitions for actual independent walls, half walls, or explicitly requested scan geometry. Do not make hidden-wall floor polygons plus a second set of partitions as a shortcut for a normally editable home. Preserve special constructions that the existing design actually needs.\n\nIn the default 2D plan view, X increases to the right and Y increases downward: top is smaller Y, bottom is larger Y. Map any source north arrow or front facade explicitly; screen top is not necessarily geographic north. Use this frame consistently for room placement and for deciding which walls are shared versus exterior. A 3D camera orbit does not change world coordinates. Confirm the arrangement in the 2D view before placing openings.\n\nKeep one coordinate plan for all floors and shared boundaries. Position APIs use **world X/Y centimeters**, with Z vertical; native property values use their returned `units`. Read creation's translation and actual outlines before placing anything. For room lengths, inspect walls with `fields:[\"geometry\",\"properties\"]`: `editorGetSceneMeasurements` supplies areas/counts, not clear spans. Establish whether the native `length` is an interior or path measurement before comparing it with the brief.\n\nMake an access graph: entrance → hall/living → each enclosed room, using actual openings. Adjacency alone does not give access. Attach a shared-wall opening once with a discovered `wallId`. Its offset locates the opening **center along the wall path**, not its near edge: for a centered opening use half the inspected path length, not half the usable wall `length`, and do not subtract half the opening width. Check its center and full model extents against corners in 2D/3D. Frame/model bounds do not establish a clear aperture width; an exact opening-width claim needs matching evidence. Multiple room-owned wall records can represent a legitimate shared wall.\n\n## Generate kitchens\n\nFor a complete kitchen layout, use `editorKitchen` when advertised. Discover its schema, call `{\"action\":\"capabilities\"}` through its JSON-string `request`, then generate with the current project hash, scene revision, a stable requestId and the actual roomId. Use returned configuration/model capabilities for wall runs, required functions, connected corners and rows. Do not replace this workflow with a preassembled catalog kitchen or manual cabinet placement; those routes require an explicit request for particular catalog objects or an accepted approximation when the generator is unavailable.\n\nInspect the nested calculation and application results. A completed operation with `no_solution` or a partial application is not a finished kitchen. Existing furniture reserves obstacle intervals: for a requested replacement, remove only the verified obsolete kitchen objects with the exact-selection gate, then calculate again with a new requestId for the changed scene. Preserve valid openings and unrelated furniture. Verify the applied module IDs, functional requirements, remaining gaps and 2D/3D result before claiming success.\n\n## Work efficiently\n\n- Keep a compact map of semantic labels → returned IDs, target hash, current revision, and unfinished operations. Keep full results locally; return only decision-relevant fields and emit image blocks separately.\n- Prefer scoped inspection over repeated full documents. `editorListObjects` pages at up to 100 items; inspect up to 50 IDs together. Set only returned editable property keys and string values; room naming uses `customName` when exposed, not guessed `name`. Native room-type labels may already satisfy the brief.\n- Batch catalog searches by role and compare shortlisted assets in one contact sheet. Pick geometry and function before finish. For exact products preserve supplied dimensions; read actual applied sizes and account limits.\n- Use `editorAddRooms` for up to five related room additions and `editorPlaceCatalogItems` for up to 25 placements. Omit `roomType` until an ID is known from `editorListRoomTypes`; room names are not type IDs. Use `editorUpdateObjects` for coherent edits with a current revision. Serialize mutations; do not fetch the entire scene between each item.\n- Inspect a completed receipt before polling. If running, wait on its operation with the documented terminal wait. Inspect the nested business result: completed + partial is not full success. Retain inserted IDs and reconcile them; never repeat a whole partially completed batch under a fresh request key.\n- Send only changes needed for the requested state. Do not rewrite a correct thickness, heading or size to repair a different measurement: a setter can clamp a value that creation already preserved. Diagnose the measurement basis and edit the actual discrepancy. `headingDegrees` is floor heading; 3D `aZ` is tilt. If native heading requires 2D, switch view and correct the existing object through the supported heading tool. Do not retry an access denial or weaken checks.\n- Selection may expand to a group. Do not call `remove` unless `editorGetSelectionActions.selected` is nonempty and matches the intended removal IDs exactly. Use an available native `ungroup`, reselect the **same saved target ID** and recheck selection before removing it; finish that target before switching groups. Clearing selection does not ungroup. If the gate cannot be satisfied, leave the group intact and report the blocker; do not delete and recreate wanted companions.\n\n## Verify and finish\n\nFor measured or reference-led work, keep a compact acceptance record: requested target and basis, observed value, evidence, and passed/failed/unverified status. At shell and final checkpoints, act on each discrepancy: correct it through a supported operation or retain the concrete blocker. Do not explain away a mismatch as a different measurement basis without evidence establishing that basis. Build the handoff from all unresolved defining checks, not just the last defect noticed; a green native validator cannot override a failed source check.\n\nAt shell and final milestones, run scoped `editorValidateScene` and inspect useful 2D/3D views. Start previews with `editorGetScenePreview({view:\"2d\",scope:{kind:\"floor\"},maxImageBytes:1000000})`, then the corresponding 3D view. Default width is 768, maximum 1024. Inspect actual image blocks and readiness, not serialized base64. A preview switches view and performs a bounded readiness wait; wait separately only for reported pending IDs, with 3D active for `ready3d`. For unreadable detail, use a relevant smaller scope. Repeat views/checks only to resolve a change or missing evidence.\n\nA clean structure result does not check intended door connections, circulation, door swing, wall clearance or exact mesh contact. After a local change, inspect the affected region and retain unresolved warnings.\n\nFor a numeric furniture-clearance claim, read [fit evidence](references/fit-evidence.md). After the 3D preview is ready, inspect the relevant furniture again with `fields:[\"geometry\",\"properties\"]`; a previous response with `bounds:null` or `model_3d_required` cannot support measured gaps. Record the gaps from those loaded bounds and the established interior boundary. Report the requested minimum and limiting side, without an invented maximum/range. If the evidence is missing, say the clearance is unverified.\n\nMoving a room carries its contents: re-read their coordinates before subsequent moves. When repairing geometry/history, verify Undo/Redo on the actual room, walls, and members, then leave the intended final state.\n\nUse normal autosave. `persistence.state=idle` with `serverAcknowledgement=not_checked` is not a save receipt. For a requested persistence test, verify a fresh load in a second tab after autosave and record what survived. Routine edits do not need repeated reloads.\n\nReturn the project link (using the native result URL or the connected Planner origin with the verified project hash), requested outcome, measured checks, and concrete unresolved issues. Keep credential-bearing URLs and signed access tokens out of reports. Skills cannot repair a renderer or native command defect; retain a minimal reproduction when one blocks the requested result.\n\nIf the brief asks how furniture looks in this interior or asks for a render after plan import, continue from the verified furnished scene through `planner5d-ai-render`. Use the same project and imported product, inspect the composed source view, and return the completed render with the editable project. Keep measured fit and image fidelity as separate outcomes.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}