fnf-blender-mcp 0.2.0 → 0.2.2

package/skills/blender-audit-finalize/SKILL.md

@@ -0,0 +1,139 @@
+---
+name: blender-audit-finalize
+description: Audit a local Blender scene against its specification, measure structural, motion and visual failures, repair them, and save requested deliverables under the local recovery policy.
+---
+
+# Audit and finalize
+
+Read [blender-scene](../blender-scene/SKILL.md) for the local session contract.
+Tool names below use its capability mapping when the named interface is absent;
+read only the relevant rows in [blender-volatile](../blender-volatile/SKILL.md).
+
+The audit compares the scene to the Scene Passport — not to memory, and not to
+the arguments of the calls that built it. A build passes only when structural,
+motion, and visual evidence all agree.
+
+## Structural audit
+
+Run `bl_validate_scene`, diff against the pre-build snapshot with
+`bl_scene_diff`, and inspect the important objects with `bl_get_object`
+(`bl_execute` only for facts the typed reads do not expose). Confirm:
+
+- every expected object exists exactly once, under its semantic name;
+- dimensions, transforms, origins, parents, collections, visibility match;
+- active camera, frame range, fps, render engine, resolution match, and
+  `frame_end` reaches the last marker and the last key;
+- material slots and texture links resolve;
+- generated replacements sit inside their proxy footprints;
+- no stray defaults, `.001` duplicates, orphan stand-ins, or hidden failures;
+- related objects found under every prefix they use — one prefix search is
+  not a sweep;
+- hero/export meshes have sane normals, manifold state, and density.
+
+## Motion audit
+
+Mandatory for dynamic-default scenes; skipped only on an explicit static
+request.
+
+- Audit motion from fresh scene reads and `bl_execute`; when diagnosing a
+  failure, enumerate animated objects/properties, key times, and interpolation.
+  This package does not provide `bl_audit_motion`.
+- Sample first/rest, departure, peak, settle, and final/loop frames.
+- Check collisions, clipping, constraint jumps, rotation flips, camera
+  framing, visibility, loop continuity.
+- The promised motion must be perceptible and purposeful.
+
+A still image cannot pass this audit.
+
+## Visual audit
+
+1. Viewed camera render for composition; inspect datablocks, modifiers and
+   rigs for editability. A desktop viewport check is unavailable locally.
+2. Inspect active-camera material, light, shadow, transparency, and engine
+   settings through fresh reads, then view a `bl_render` output. The package
+   does not provide `bl_audit_render`.
+3. For dynamic scenes, call `bl_set_frame` and `bl_render` at representative
+   frames; view each result. There is no `bl_render_contact_sheet` tool.
+4. View the returned evidence — success JSON says nothing about appearance.
+   And view it at scale: image previews downsample, so few-pixel features
+   average away to nothing. Crop 1:1 and count bright pixels numerically
+   before concluding something did not render.
+5. **Unreachable evidence fallback** — when a render/screenshot URL cannot
+   be opened (network policy, expired link), report that retrieval failure
+   and obtain equivalent evidence at an accessible local path. Write camera
+   renders via `scene.render.filepath` +
+   `bpy.ops.render.render(write_still=True)`; obtain a local viewport capture
+   if the claim specifically concerns viewport state. Actually view the
+   replacement evidence. If it cannot be viewed either, mark the relevant
+   visual check `blocked`, give the user the available paths/URL, and never
+   substitute numeric proxies for appearance. Numeric proxies cover
+   structure and motion only.
+   One useful framing proxy:
+   `bpy_extras.object_utils.world_to_camera_view(scene, cam, world_co)`
+   returns NDC — x/y in `[0,1]` **with z > 0** means in-frame (z ≤ 0 is
+   behind the camera) — but NDC cannot tell a cylinder from a cactus.
+
+Check silhouette hierarchy, scale cues, contact, depth separation, texture
+scale, highlight/shadow detail, generated/local style coherence, and delivery
+framing. One extra rule: **no asset may read as an unresolved primitive from
+the active camera** unless its passport fidelity is `blockout`. A bare
+cylinder standing in for a cactus, or a uniform sphere for a rock, fails this
+check even when every structural metric passes.
+
+## Specialist audits
+
+Owned by their modules, executed here at finalize time when the Scene
+Passport declares the matching work:
+
+- **Cinematic lighting** (cinematic, commercial, product, night, atmosphere,
+  reference-matched): the full "Lighting audit" in
+  `blender-lighting-camera`. If isolated or grayscale evidence cannot
+  be produced, the lighting audit is `blocked`, not `passed`.
+- **Generated environment**: the "Audit gate" in `blender-hdri`. Record
+  the SDR limitation; a GPT Image PNG is never reported as true HDR/EXR.
+- **Generated PBR material**: the "Audit gate" in `blender-pbr`.
+  Luminance-derived maps are inferred, not measured.
+
+## Measuring a complaint
+
+- Measure the quantity that was complained about, in world space over time —
+  never the nearest available proxy. A perfect reading on the wrong quantity
+  closes the wrong case, and the complaint returns.
+- A clean zero can be the failure. A component that never varies proves rigid
+  parenting as readily as correctness; pick the reference frame the physical
+  claim is about — for a wheel that is the ground, not the body.
+- A hidden object returns a stale matrix. Measure on a frame where it is
+  visible.
+- `scene.ray_cast` follows viewport visibility, not render visibility. When
+  the ray and the render disagree, the render is the evidence.
+
+## Repair loop
+
+Fix the largest concrete failure first, then rerun the affected audit. No
+polishing of secondary detail while scale, framing, contact, or motion is
+wrong. A blocked check is reported as blocked — never dressed up as a pass.
+
+## Finalize
+
+- Modifiers, rigs, materials, and generated assets stay editable unless the
+  deliverable explicitly demands destructive application.
+- Proxies are removed only after their replacements pass; otherwise they are
+  parked predictably and reported.
+- Restore a useful frame and the intended active camera.
+- Record generated job ids, models, estimates, imported object names.
+- Report created/modified/deleted objects with the audit evidence.
+
+When `bl_finalize_build` is exposed, run it once after repairs and inspect
+its documented result; a `valid` field must be true when that is the contract.
+Otherwise use the core manual-finalize fallback and report each audit result
+with its actual evidence. Do not invent a tool response or silently convert a
+blocked generation, export, or visual check into a pass.
+
+## Save policy
+
+Follow blender-scene's local save and recovery contract. Recovery copies
+precede broad/destructive edits; save requested .blend outputs before
+reconnecting or replacing the active project. Preserve useful partial work
+even when an audit is blocked, clearly reporting its status. Confirm an
+ambiguous overwrite target; do not overwrite or pack resources merely as a
+side effect of audit/finalize. Report the verified saved path.

package/skills/blender-camera-blocking/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: blender-camera-blocking
+description: Camera blocking and mise-en-scène in Blender: decide where the actors stand and move, where the camera sits, and what the lens actually sees, using the bundled Blockstage add-on. Draw parametric rooms with doors and windows, furnish them from a 42-piece library, place and pose four rigged characters with IK/FK, hand grips and held props, and set the camera to match a reference frame or a written brief. Use for previsualization, shot planning, staging and blocking rehearsal, coverage and eyeline checks, camera height and lens choices, and any scene blocked quickly from ready-made adjustable parts; installs and enables the add-on on first use. For geometry modelled from scratch use blender-modeling or blender-greybox. Not for character modeling, rig construction, add-on development or skill authoring.
+---
+
+# Camera blocking and mise-en-scène
+
+Build editable scenes with the bundled Blockstage 0.3.0 assets and controls. Match the requested composition and level of detail while keeping the scene practical to adjust in Blender.
+
+## Start with Blender
+
+At the beginning of each invocation, inspect the available Blender connection and enabled Blockstage version. Immediately install or enable the bundled dependency when needed by following [Add-on Installation](references/addon-installation.md). Reuse an enabled, complete 0.3.0 installation without reinstalling it. Installing the skill folder alone does not execute Blender operations; dependency setup runs when the agent uses this skill.
+
+Identify the active file, scene, collection, camera, frame range, and existing animation before editing. Use the supplied reference or written brief and the user's requested output location. Preserve a recoverable copy before replacing substantial existing work or switching files. Keep unrelated objects and animation intact. Ask only for information that materially blocks construction; resolve ordinary layout choices yourself.
+
+## Establish the composition
+
+For an image, identify its aspect ratio, perspective, camera height, subject proportions, overlaps, contact points, and dominant shapes. Match framing with coarse native assets before adding smaller objects. For a written brief, establish a clear room arrangement, circulation route, and camera position appropriate to the requested action.
+
+Use a dedicated collection for a new setup inside an existing file. Keep native asset hierarchies together and check where the add-on places newly generated objects. Use English names for scene elements. During a local correction, preserve the established camera unless the correction requires a framing change.
+
+## Construct through native controls
+
+Load [Layout and Assets](references/layout-and-assets.md) when constructing rooms, openings, furniture, colors, or lighting. Build architecture and major furniture first, then add the secondary props needed for the composition. Use native editable controls instead of replacing supported assets with improvised geometry.
+
+Load [Character Staging](references/character-staging.md) when adding, duplicating, posing, or attaching props to actors. Keep characters at the native blockout detail level unless the user requests additional detail. Add keyframes only when animation is requested; preserve the requested duration and frame rate.
+
+Load [Live Construction](references/live-construction.md) when the user requests visible progress or records the screen. Otherwise, use the available Blender tools directly without unnecessary interface changes.
+
+## Save the scene
+
+Save the requested editable blend file with working asset roots, rig controls, camera, and scene organization. Keep newly introduced external resources available through packed data or portable relative paths. Produce images or video only when requested. Report the saved location and any actual unresolved limitation briefly.

package/skills/blender-camera-blocking/references/addon-installation.md

@@ -0,0 +1,17 @@
+# Add-on Installation
+
+## Bundled dependency
+
+Use the bundled [Blockstage 0.3.0 installation-unlocked variant](../assets/Blockstage-0.3.0.zip), resolved relative to this skill. Its installation version threshold has been relaxed; functional code, the license, character library, and thumbnails are preserved. The relaxed installer metadata does not establish compatibility with every Blender release. Its manifest identifies blockstage version 0.3.0. No separate Cast installation is needed.
+
+## Automatic setup
+
+Perform dependency setup as part of the requested Blockstage workflow, without asking the user to install it manually or seeking redundant confirmation. Use the user's installed Blender through the existing connection or native interface. This skill imposes no specific Blender version; establish compatibility through the native installer's result, extension registration, and asset loading. Discover the actual extension repository and registered module in that Blender installation; do not assume a user directory or module prefix.
+
+When installation is needed, use Blender's native Install from Disk operation in Edit, Preferences, Get Extensions. Select the bundled ZIP directly and enable the installed extension. The native operation is also exposed as extensions.package_install_files for tools that provide Blender API access. Save the enabled preference in the same Blender session. Do not create or require a separate installer script.
+
+If 0.3.0 is already installed but disabled, enable it. If another version or a legacy copy conflicts, preserve its recoverable files and settings, disable only the conflicting Blockstage registration, and install the bundled version through Blender's extension manager. Do not enable duplicate copies. Preserve unsaved scene work before any necessary restart. Avoid changing preferences through a background Blender process while the user's Blender is open.
+
+Confirm the registered version and the Blockstage sidebar in the 3D View. Confirm that Room Builder and Man, Woman, Heavy Man, and Heavy Woman are available, including the cast library and thumbnails. Copying an archive alone is not a completed installation. Existing characters in older scenes are not automatically replaced by installing the extension.
+
+If Blender access, the archive, or a required permission is unavailable, state the exact missing requirement and request only what is needed. If Blender rejects the extension or its character library, report the actual compatibility error without bypassing installation checks or claiming unsupported compatibility. Do not report installation success or substitute another asset system. Skill instructions cannot bypass tool permissions or create a Blender connection themselves.

package/skills/blender-camera-blocking/references/character-staging.md

@@ -0,0 +1,19 @@
+# Character Staging
+
+## Native actors
+
+Choose Man, Woman, Heavy Man, or Heavy Woman. Preserve each actor's meshes, weights, rest pose, constraints, widgets, and internal references. Use Duplicate Asset to copy the complete native hierarchy with remapped references. Do not reconstruct an actor from primitives or add facial features, clothing, or hair unless requested.
+
+Native actors face negative Y with Z up. Pose coordinates are in armature space, while an asset parented to a room can use room coordinates. Inspect the evaluated world transform before positioning controls or attachments. Move the actor through its whole asset root rather than offsetting unrelated body parts.
+
+## Poses and contacts
+
+Use Selected Asset, Pose Controls for body, head, shoulder, hand, foot, elbow, and knee controls. Pose presets establish a static starting pose; Walk is not a walking animation. Presets reset pose controls, grip, and foot roll, so do not apply one over existing posing or animation without a requested reset.
+
+Establish ground or seat contact, then adjust pelvis and torso balance, limb targets, pole controls, head direction, and hand orientation. Keep knees and elbows bending coherently without stretching limbs. Match head direction to the intended target rather than assuming the body's facing direction is sufficient.
+
+Use Snap to IK or Snap to FK when changing control modes while preserving the current pose. Unsupported FK twists can be rejected with the pose retained; resolve the incompatible pose before switching. A manual IK/FK blend is not equivalent to snapping. Use native Roll and Bank for foot pivots.
+
+Hand Grip supports Open, Hold, and Fist. Rig Details, Fingers provides individual phalanges with Curl and Spread. Use Attach to Hand for held props, then align the grip and the prop's functional direction. The native pistol points along negative Y before additional transforms.
+
+When animation is requested, Key Pose records the actor transform, editable controls, fingers, and custom properties. Animate these controls rather than driven mechanism bones. Keep meaningful keys editable and preserve existing timing unless the request changes it.

package/skills/blender-camera-blocking/references/layout-and-assets.md

@@ -0,0 +1,19 @@
+# Layout and Assets
+
+## Rooms and openings
+
+Use Rectangle or L-shaped room controls for simple plans and Draw Room for a custom closed outline without self-intersections. Set dimensions and wall thickness before decorating. Floor Plan and Overview help establish circulation and camera access. For adjacent rooms, avoid duplicate shared walls and align their actual passage openings.
+
+Disable a wall through its checkbox in Walls & Corners. Deleting its generated mesh is temporary because rebuilding restores it. Use Edit Outline, Split Wall, and Remove Corner to change the plan. Resolve affected openings before changing the number of walls; wall numbers follow the ordered outline rather than screen direction.
+
+Door, Window, and Passage generate real openings. Position their centers with From Wall Start on the correct Wall Number, then set their dimensions and sill where applicable. Use Reposition on Wall instead of moving generated opening geometry independently. Door Open Angle can be animated. Windows provide open frames without a glass shader.
+
+Cutaway, Complete, and Open Top affect rendering as well as the viewport. Choose the mode intentionally for the camera; ceiling fixtures can remain visible in cutaway mode. Use Ceiling and Trim controls for structural changes. Room dimensions are layout controls, not a substitute for animated geometry.
+
+## Furniture and lighting
+
+Choose native furniture from the thumbnail library. Place supports click placement and rotation; Object Properties provides Add at the 3D Cursor. Use Select Root and the asset's Dimensions to transform a complete piece. Moving an arbitrary child mesh breaks the intended assembly. Room resizing preserves furniture positions, so adjust their arrangement when the plan changes.
+
+Room furniture presets require a rectangular room at least 4.8 by 4.8 meters. They add independent assets and do not replace existing furniture. Prefer individual placement when matching a reference. Thumbnails show the default assets, not a live depiction of customized geometry.
+
+Mount ceiling fixtures through native room controls and adjust Ceiling Drop and Light Power. Keep lighting readable for the requested shot. Furniture Color affects an entire asset; separately rooted child assets remain independent. Walls Color covers the wall assembly, including its trim and opening parts. Floor and ceiling colors are separate. Use these controls for simple color blocking; create additional shaders only when requested.

package/skills/blender-camera-blocking/references/live-construction.md

@@ -0,0 +1,7 @@
+# Live Construction
+
+Work in the user's visible Blender session when showing progress or supporting a screen recording. Establish a readable viewport before construction. Keep the scene visible while using native tools through the available interface or connection; do not replace visible work with an unseen background build.
+
+Make coherent changes in successive passes for the room, major furniture, actors, poses, and final camera composition. Let Blender redraw after each pass so the user can follow what changed. Give brief updates tied to the visible result. Do not repeatedly change workspaces or leave consoles covering the scene.
+
+Use floor or perspective views when they explain placement, then return to the scene camera. During animation work, show the affected interval through playback after a meaningful change. Never present saved snapshots as evidence of a live update when the open Blender scene has not changed.

package/skills/blender-camera-led-assembly/SKILL.md

@@ -0,0 +1,48 @@
+---
+name: blender-camera-led-assembly
+description: Use when the user asks for a scene or product breakdown, build-up, or assembly animation. Create or revise editable Blender animations with expressive staged appearance, overlapping construction, and temporary internal assembly while preserving the agreed final look. Include camera or whole-product motion when requested. Exclude written scene analysis, static modeling, unrelated camera-only work, and animation outside Blender.
+---
+
+# Camera-Led Assembly
+
+Apply this skill automatically to scene or product breakdown, build-up, and assembly animation requests, without requiring the user to name the skill. Interpret breakdown in this context as an animated construction or appearance effect; an explicit request for written analysis alone falls outside this scope.
+
+Create an expressive, coherent appearance animation from the existing scene. Develop a visual idea specific to its construction, materials, and camera view. Keep the result editable and recover the agreed final appearance exactly within measured rendering limits.
+
+## Scope and live state
+
+Preserve existing geometry, materials, UVs, normals, placement, lighting, visibility, and camera behavior by default. Apply explicit changes to the identified scene only and establish the revised baseline before judging preservation. Temporary construction geometry may strengthen the effect; remove its visible, shadow, reflection, and instance contributions before the final state.
+
+Read [blender-scene](../blender-scene/SKILL.md) for the local session contract, or load it with `bl_get_skill(name: "blender-scene")`, and follow its routing for the modules actually needed. Check `bl_health` and `bl_get_scene_summary` before edits. Prefer specific callable tools; use Blender Python for topology analysis, bulk animation, and checks when those operations require it. Report unavailable dependencies and choose a supported route within the authorized scope.
+
+Recheck the live file and active scene after user steering. Record unsaved state, camera, frame range, frame rate, aspect, and neighboring scenes. Locate the requested project from that evidence and the supplied files. If the source or a necessary final-state decision remains unresolved, ask for that missing input before dependent edits. Preserve a recovery copy before broad changes. An older checkpoint must not replace unrelated live edits; an isolated revision can be appended as a separate scene.
+
+This server drives a dedicated background Blender process and cannot see an open desktop window. When the user refers to an asset they just opened on screen, that file is not the session's file: ask for its path and open it with `bl_open_project`, rather than assuming the background scene already holds it. Save .blend files before disconnecting; unsaved state is lost on reconnect. Preserve and transfer the actual selected asset before replacing its environment with a procedural substitute.
+
+Read [Blender mechanics](references/blender-mechanics.md) before copying or reparenting scene data, handling instances, or changing animation channels. Record the protected source state and capture its evaluated camera view before editing.
+
+## Choose the construction idea
+
+Distinguish a single hero product from an environment with many visual subjects, independently of object count. Load [Product assembly](references/product-assembly.md) for a hero product or temporary internal construction. Load [Environment assembly](references/environment-assembly.md) for architecture, vegetation, or repeated scene assemblies.
+
+Consider distinct concepts and choose the strongest readable one autonomously. Record the chosen idea, dominant connections, protected elements, duration, mechanism families, and completion criteria in a compact working plan. Define whether the requested empty start covers the subject or the whole visible scene. Existing fixed backgrounds can remain when that matches the shot.
+
+Derive parts from construction, seams, materials, connected geometry, and attachment points. Each repeated family shares a construction method; timing and emphasis may vary. Part count is useful only when it improves the visible assembly.
+
+## Choreograph overlapping motion
+
+Build local dependencies and overlapping events across visible regions. Supporting structures must be ready when contact occurs, while approaching components may already be moving. Keep one dominant connection readable as supporting motion continues. Choose duration and final hold from the shot, then convert timing using its actual frame rate.
+
+Match motion to physical role. Rigid modules approach at working size, align, retain a readable gap, and seat smoothly. Structural members extend from attachments. Hinged surfaces rotate around their connections. Flexible components unfold or unbend according to their support and material. Repeated details join in overlapping waves. Short materialization may establish a part, but the subsequent assembly must remain visually distinct across these mechanisms.
+
+Use semantic controllers and record each event's source, family, attachment, final transform, interval, motion, and temporary status. Compute contacts against the support's evaluated pose. Preserve smooth velocity through intermediate keys and retain intentional timing accents. Judge continuity by visible movement and attention, not merely by the existence of active curves.
+
+Use the existing camera unless its revision is requested. Load [Camera choreography](references/camera-choreography.md) when changing camera motion, framing, or whole-subject travel. Coordinate these changes with local assembly and the agreed endpoint.
+
+## Verify and deliver
+
+Plan and inspect through the evaluated camera. Keep approaching panels and foreground surfaces clear of important connections. Projected bounds locate suspect intervals; rendered views resolve actual occlusion. Recheck the complete affected interval after changes to paths, pivots, timing, or camera motion.
+
+Load [Validation and delivery](references/validation-delivery.md) for final comparison, sequential rendering, export, and transmission. Finish with the agreed native scene, a verified preview in the requested shading, and the authorized deliverables. State the meaningful changes, preservation result, and any unresolved limitation.
+
+When the user also requests a process case study inside an existing media template, read [Case template](references/case-template.md). This is an optional delivery step, not a reason to alter every assembly task or publish to an external channel automatically.

package/skills/blender-camera-led-assembly/references/blender-mechanics.md

@@ -0,0 +1,45 @@
+# Blender State and Animation Mechanics
+
+## Evaluated source state
+
+Activate the relevant scene and view layer, set the intended frame, and update evaluation before measuring world transforms. Newly loaded inactive scenes can expose unevaluated matrices. Activate an animated source at its reference frame before comparing it with a frozen assembly copy. Preserve the source animation and record the selected pose explicitly.
+
+Inspect hierarchy, constraints, drivers, action slots, NLA, shape keys, simulations, modifiers, and shared datablocks before edits. A copied scene must have a persistent user; verify its presence after saving and reopening. Protect other scenes when replacing objects or unlinking shared collections.
+
+## Copies and attachment transforms
+
+Keep native sources intact. Separate evaluated geometry when necessary and preserve materials, UVs, normals, and complete face coverage. Restrict spatial partitioning to an identified surface whose topology has been checked. Applying subdivision independently to cut source meshes can change their boundaries and silhouette.
+
+Compute each part's final local transform from its preserved world transform and the inverse of the final parent transform. Place the controller at the actual attachment, compensate the child's local transform, and measure the assembled result after evaluation. Copy original transform components, rotation mode, delta transforms, and parent inverse directly when preserving an existing hierarchy; unnecessary matrix decomposition can introduce error.
+
+Nonuniform parent scale combined with rotation can produce shear that an isolated transform cannot represent. Preserve that hierarchy or bake the complete affine transform into temporary geometry with correctly transformed normals. Verify the chosen route against the source, including dependent particles.
+
+## Animation ownership
+
+In Blender 5.1, address the channelbag belonging to the animated datablock's action_slot handle. Camera data, shape keys, and objects can occupy different slots. animation_data_clear followed by key insertion can reconnect an existing action containing old keys. Clear only owned channels in the correct slot or assign a fresh owned action, then inspect the actual curves.
+
+Retiming must update key times and both handle times consistently, together with event metadata and dependent visibility. Preserve deliberate easing. Smooth sampled trajectories need continuous tangents through intermediate keys; repeated easing at every sample can introduce pauses. Check settled intervals for returning scale, deformation, or visibility keys.
+
+Animate hide_render and hide_viewport consistently with constant visibility transitions. Hiding an Empty does not reliably hide its children. Also inspect hide_set, collection exclusions, and modifier visibility. Keep required constraint targets evaluated.
+
+When permanently superseding a renderable object in the revision, remove its owned visibility F-curves or key a constant hidden state across the full shot. Clearing keyframe points while leaving an empty visibility channel is not proof that a directly assigned flag will persist through file reload and render evaluation. Check the sequential render, including other actions, drivers, and NLA that can restore it.
+
+## Instances and memory
+
+Inspect evaluated instances even when a procedural root has no mesh faces. Copy instance identity and matrices while iterating; do not retain transient depsgraph instance wrappers. Copy metadata arrays into independent plain values before removing their owning datablocks.
+
+Share animated prototypes when that preserves per-instance timing and construction. Duplicating expensive procedural evaluation for every visible instance can make a scene unusable. Validate the actual evaluated repetitions and their final transforms before expanding the method.
+
+## Geometric reveal and flexible detail
+
+Solid appearance must change geometry, transforms, or visibility. Shader transparency alone is insufficient. For Geometry Nodes reveal, verify attribute space, modifier order, face selection, and the appearance of open boundaries. An origin offset is not a general substitute for evaluating a moving hierarchy's coordinate system.
+
+Open-surface normal recalculation can orient disconnected terrain patches inconsistently. Compare copied face winding and normals with the native source; for a verified heightfield, upward-facing surface normals provide an additional check. Do not force this rule onto overhangs or closed meshes. After welding, re-evaluate orientation and smoothing. Preserve source corner or vertex normals on aligned temporary fragments when a later handoff would otherwise create visible shading seams.
+
+Flexible temporary copies can use shape keys or suitable deformation modifiers. Deform regions consistently with their thickness, seams, attachments, and support; a soft material on a rigid backing does not make the whole assembly flexible. Curve reveal can control a continuous winding path. Confirm that the evaluated shape returns to its undeformed state before handoff; a zero controller value alone is insufficient evidence.
+
+Particle and hair behavior must be checked in sequential rendering. Cached strands can lag behind otherwise correct moving copies. If temporary geometric strands are required, derive them from the existing paths, preserve their radii after transforms, and return the untouched native emitter only after seating. A nominal hair length may not describe edited paths. Remove all temporary strands in the final state.
+
+## Viewport integrity
+
+Preserve the user's viewport overlays and unrelated display settings. Use a valid view and region context for viewport capture, and inspect the resulting image. A Workbench render has its own display profile and must be evaluated separately from UI capture.

package/skills/blender-camera-led-assembly/references/camera-choreography.md

@@ -0,0 +1,25 @@
+# Camera and Subject Motion
+
+## Establish the endpoint
+
+Record the agreed framing endpoint. If the user requests a revised final composition, compare source geometry and assembled geometry through that same final camera.
+
+Choose a continuous path that reveals useful connections at the moment they occur. Set orbit extent, distance, height, focal length, and settling time from subject scale and composition. Camera movement should support the current assembly accent and settle coherently with completion. Past shot dimensions and angles are not presets.
+
+## Orbit the visible subject
+
+Derive the orbit centre from the actual subject geometry. An existing tracking target may sit along the viewing ray well in front of the product. Orbiting that helper can send the product out of frame despite valid camera tracking.
+
+Preserve the established framing offset when it is intentional. A temporary camera and temporary tracking target can move together around the actual subject centre. A semantic parent rig that returns to identity allows the original transform components and constraint relationship to be recovered without unnecessary decomposition. Verify this against the evaluated endpoint, including lens, shift, scale, and rotation.
+
+Keep the original camera recoverable. Animate owned controllers and inspect their actual evaluated motion; assigning plausible keys is insufficient. If a copy inherits source constraints, verify their targets and transform spaces after parenting.
+
+## Coordinate subject travel
+
+Whole-subject travel and local assembly need separate controls. Components should approach and connect relative to the moving subject. Coordinate wheel rotation or other visible contact mechanics with translation when present, and preserve the agreed final placement. Avoid adding travel to unrelated scene elements.
+
+## Validate the path
+
+Project current animated geometry through the evaluated camera over the full shot, using the real aspect and pixel aspect. Check partial clipping and near-plane crossings as well as complete loss from frame. Resolve ambiguous foreground blocking with camera rays and rendered views of the affected interval.
+
+Account for fixed backgrounds and enclosures newly exposed by the path. Repair the trajectory, target, or assembly approach within the authorized composition. Inspect meaningful stages and actual playback for readable parallax, smooth acceleration, and a deliberate finish.

package/skills/blender-camera-led-assembly/references/case-template.md

@@ -0,0 +1,23 @@
+# Optional process case study
+
+Use only when the user requests a process demonstration or media-kit composition in addition to the Blender assembly.
+
+Inspect the actual open template: application edition, file, active composition, dimensions, frame rate, layer sources, parent transforms, masks, logos, music, and timing. Save a recovery copy of live state. Duplicate the requested main composition and only the content branches that need independent edits; replacing a shared FootageItem can change the original template as well.
+
+Measure the template's content apertures and preserve its chrome, logos, layout, and music when requested. Fit the complete hero video inside its aperture without cropping important assembly. A square media-kit wrapper can contain the requested 16:9 scene montage; preserve the wrapper's established layout unless the user asks to redesign it.
+
+Create a single timing map for the hero, interface recording, and prompt narrative. Match each segment to the same scene and construction stage. For a time-lapse, record or stage meaningful interactions with the actual editable project: functional parts, attachment controllers, animation curves, environment assembly, and camera checks. Keep the cursor, selected controls, and resulting scene states consistent. Retiming a recording does not excuse showing unrelated buttons or a different project.
+
+When reconstructing missed process footage, present it as a process replay or demonstration. Translate or summarize prompts faithfully, without claiming that translated wording is a verbatim historical log. Exclude unrelated conversations and private data from captures. Screen recording, a staged cursor overlay, or editable native chat graphics can be selected according to the user's requested format; do not silently substitute a static still for a requested recording.
+
+Verify a short sample from the actual recorder before a long take. An app-specific accessibility screenshot can show a background window while a display recorder captures a different foreground app. With multiple displays, verify the recorded display and visible window; do not infer the source from a successful UI click. Keep the recorder's original project locally and trim away setup footage before delivery. For timed demonstrations, record the capture start and action start so all four scene boundaries can be aligned exactly. A reconstructed cursor must point to the control whose visible state changes, and the translated chat copy should remain editable.
+
+Extend content and music to the requested duration without slowing the assembled hero or adding unwanted transition effects. Keep new overlays and text editable. Inspect the complete exported wrapper in playback: synchronized segments, readable lower panels, preserved logos, framing, sound, first/last frames, duration, and frame rate.
+
+Check the decoded recording's actual frame count, not just the requested recording or trim duration. A nominal 25-second recording can contain only 598 frames at 24 fps. Map the last output frame to a valid source frame and extend the layer's out-point, so the interface does not disappear at the end. Inspect both sides of every scene cut: UI redraw latency can shift a recorded scene change by one or two frames. Use a per-scene time map to align the recording to the hero cuts without pulling the next scene into the preceding shot.
+
+Deliver the native project and authorized exports. Verify actual transmission before marking delivery complete. Follow the most recent instruction about keeping the computer awake or shutting it down; these are session-specific actions, not default skill behavior.
+
+When multiple AE editions are running, target the exact edition and read back its project path and version. If native scripting dispatches through BridgeTalk, retain and inspect error callbacks: a successful send only proves message acceptance. ExtendScript uses an older JavaScript grammar; avoid reserved identifiers such as `short` even for object fields. Inspect actual render output before repeating a timed-out mutation, so the retry cannot duplicate content branches.
+
+In AE, removing every time-remap key can disable time remapping and hide the property. Add the intended keys first, then remove obsolete default keys while retaining the new ones. Verify the final rendered frame after the change; a saved project or a middle-frame preview is insufficient.

package/skills/blender-camera-led-assembly/references/environment-assembly.md

@@ -0,0 +1,27 @@
+# Repeated Environment Assembly
+
+## Local construction
+
+Infer architectural stages from the existing structure and visible connections. Assemble supports, enclosing surfaces, openings, and finishing elements with local dependencies. Temporary framing can clarify construction where the source lacks internal structure, but native surfaces must define the completed scene.
+
+Apply one construction technology throughout each repeated family. Distant or instanced assets still need that technology; their timing, duration, and emphasis can be reduced to suit the camera. Validate a representative mechanism before expanding it, then inspect the evaluated distant instances as well as nearby objects.
+
+Distribute overlapping activity across the camera's visible regions. Completion of an entire category must not become a global barrier to the next category. A tiny moving detail in the distance does not establish an engaging flow after a dominant foreground event has stopped.
+
+## Vegetation and organic structure
+
+Derive branching from actual connectivity, thickness, depth, and attachment points. Reveal the trunk into connected branches and finer growth while retaining the source's seasonal state. Foliage appears only when it belongs to the agreed scene. Each branch should emerge from its own connection; uniform growth of the whole crown does not establish branching construction.
+
+Inspect procedural scatter roots, prototypes, collection instances, and supporting geometry together. If the user requests vegetation removal, trace and remove its contributions only from the target scene, preserving shared resources used elsewhere. Establish the requested vegetation-free scene as the new comparison baseline.
+
+## Enclosures and foreground surfaces
+
+Ground and enclosing surfaces may use directional geometric reveal when their topology supports it. Moving or scaling a closed enclosure also moves its caps; an apparently safe final boundary can conceal a brief camera obstruction. Inspect the complete trajectory of walls, ceilings, foreground panels, and barriers. Exterior surfaces invisible from the working camera can remain stationary when animating them adds no useful assembly action.
+
+## Floors, roads, and terrain
+
+Treat a requested floor reveal as construction of the visible floor surface. Broad strips that finish before the viewer can read them may need smaller floor cassettes or planks. Derive panels from the original surface, carry its UVs and footprint, and place thickness below the finished plane. Seat the local floor before furniture feet or podium supports arrive; a whole-room floor completion barrier is unnecessary.
+
+For moving cars, evaluate tire trajectories against the assembled road. Build subgrade and local deck supports ahead of contact while shoulders, markings, railings, and surrounding hills overlap. Ground beyond the asphalt should cover the camera's full travel corridor. Reserve an explicit assembled interval before the cut; exclude vehicle translation, wheel rotation, and camera travel from assembly retiming. Verify that all assembly channels stay settled throughout that interval.
+
+Partition an imported landscape by its geological form: valley floor, slopes, cliff beds, and coherent spatial districts. Preserve native face coverage. Rise and settle neighboring districts with overlapping timing; avoid a stack of large floating sheets that blocks the product or camera. Use actual source topography to choose a clear valley for product docking and the camera path.

package/skills/blender-camera-led-assembly/references/product-assembly.md

@@ -0,0 +1,25 @@
+# Product Construction and Closure
+
+## Read the product
+
+Study the silhouette, seams, openings, thickness, attachment axes, and available internal space from useful angles. Identify existing internal geometry before adding anything. For an exterior-only model, form a restrained functional construction hypothesis and mark added internals as temporary artistic approximations. An exact engineering reconstruction requires verified references appropriate to that request.
+
+Choose internal masses and connections for what the working camera can distinguish. Their positions and dimensions must fit the actual housing profile. Add detail where it makes a connection understandable. Preserve the source product's design and permanent contents.
+
+## Make assembly legible
+
+Show functional internal groups before closing the housing. Let neighboring groups approach while the main connection seats. Attached components should move coherently with their support, with local docking timed to the evaluated attachment position.
+
+Repeated optical stacks can combine axial approach with turning, but rotation of a perfectly symmetric part may contribute little visible change. Judge the layered gaps and connections in the image.
+
+Flexible circuits need an appropriate substrate and attachment direction; conductors and substrate must deform together. Continuous winding should follow the actual path of the temporary component and finish before its connection is covered.
+
+## Keep closure clear
+
+Choose housing pivots from their connections and test the full moving surface. A panel can fit in its final position while its rotating edge clips the frame, crosses the camera, or cuts through internal modules. Bound its rotation and approach, and time closure so the important interior action remains readable.
+
+When closure obscures construction too early, revise its start, path, pivot, or temporary surface partition. Keep the assembly flow overlapping during the correction. Preserve the final panel shape and position.
+
+Check internal fit against the real shell. Thin or curved covers can expose helpers that appear to be contained by their bounding box. Seat or retract temporary internals behind the covering surface before removing them.
+
+For transparent housings, hiding helpers still matters even when they are physically inside. Return the native contents and optical appearance at the agreed endpoint. Source surface copies can hand back to native objects by functional family once their shapes and transforms match; ensure that copies and originals never remain visibly doubled.

package/skills/blender-camera-led-assembly/references/validation-delivery.md

@@ -0,0 +1,33 @@
+# Verification, Rendering, and Delivery
+
+## Structural and motion evidence
+
+Compare protected transforms, geometry, materials, hierarchy, visibility, and camera data against the correctly evaluated baseline. Confirm source face coverage after partitioning and the absence of temporary geometry and instances in the final state. Check the intended empty start across all renderable object types.
+
+Inspect repeated families for actual matching construction, including their evaluated instances. Verify deformation reset and absence of returning keys after settlement. Use current projected bounds to locate framing risks, then inspect rendered images for occlusion. Important construction must remain visible while the scene develops.
+
+## Handoff and visual comparison
+
+Compare source and assembled states at the same camera, dimensions, display profile, and reference pose. Keep native lighting and materials separate from temporary Solid export settings. Mesh partition boundaries can change cavity or normals; returning native sources after geometric alignment can remove these differences. Inspect the handoff without overlapping both representations.
+
+Compare a candidate handoff frame with and without temporary internals. Correct visible exposure before removal. Movement between adjacent frames is not a valid isolated measure of handoff error when the camera or subject is also moving.
+
+State pixel differences according to the evidence. Exact agreement between isolated still renders does not prove bitwise identity of the sequential video. Antialiasing, shadow behavior, and caches can differ between those rendering paths. Investigate visible discrepancies and distinguish measured geometric agreement from renderer-dependent image differences.
+
+## Sequential render and review
+
+Prefer Blender's native animation rendering mode for a complete sequence when it is substantially faster than separate still renders. Use a current isolated checkpoint for background rendering when that keeps the live application responsive. Confirm that it contains the correct scene, action state, camera, and dependencies.
+
+Use one documented Workbench profile for Solid output and its baseline. If large surfaces exhibit Workbench shadow artifacts, inspect the source under that same profile before attributing the defect to assembly. A justified export-profile adjustment must be applied to both comparison renders and must preserve the native scene's lighting setup.
+
+Render the full current sequence and inspect actual video playback. Contact sheets and active-curve counts cannot establish smooth rhythm or absence of cached-geometry problems. Check that the main action remains legible, mechanisms appear distinct, and repeated families remain consistent. Confirm the decoded frame when using playback or seek controls.
+
+After any relevant revision, regenerate affected outputs and dependent passes. Verify current export logs, frame count, frame rate, duration, dimensions, codec, and decoded media. Keep export parameters separate from animation retiming. File existence alone is insufficient evidence of a fresh successful export.
+
+## Save and transmit
+
+Save the agreed result and reopen it to verify scene persistence, active camera, and animation range. Leave the live application in useful shading and respect any frame the user is currently inspecting. Keep intermediate files, backups, and review history outside the deliverable package.
+
+Deliver through the user's authorized channel. Reuse authorization already established for the same result and recipient, and never infer another destination from stored project notes. Before transmission verify the exact filename, recipient, and attachment preview. Afterward confirm the delivered file identity and transport status; a correct caption does not prove that the correct attachment was sent.
+
+Summarize the visible mechanics, camera changes, duration, preservation evidence, and any unresolved limitation. Identify temporary internal construction as approximate when that affects how the result should be understood.

package/skills/blender-destruction/SKILL.md

@@ -0,0 +1,24 @@
+---
+name: blender-destruction
+description: Create or revise editable building collapse in Blender when masonry must separate into independently simulated bricks, with segmented steel framing and physical glass shards. Use for assembly, failure tuning, native simulation, or delivery of that workflow. For geometry modelled without a collapse use blender-modeling, and for keyframed rather than simulated motion use blender-animation. Exclude isolated mesh fracture, vehicle crashes, bridge failure, and video editing alone.
+---
+
+# Blender destruction
+
+Produce an editable collapse whose claimed bricks, steel segments, and glass shards remain independent native rigid bodies. Preserve the requested building, failure mechanism, damage scope, and output format. This package supplies workflow guidance, not a generator, asset library, or physics engine.
+
+## Establish scope and capability
+
+Recover scale, protected regions, trigger, fragment budget, material assumptions, seed, timing, and output location from the scene and conversation. Choose ordinary presentation defaults autonomously. Clarify missing information only when it materially changes the subject, failure mechanism, or deliverable. Previous project dimensions, fragment counts, release frames, acceptance tolerances, and solver values are case evidence, not defaults.
+
+Read [blender-scene](../blender-scene/SKILL.md) for the local session contract, or load it with `bl_get_skill(name: "blender-scene")`. Check `bl_health` and `bl_get_scene_summary` before edits. Verify the actual Blender executable and version rather than relying on an application name; this workflow was exercised in Blender 5.2.0 with native Bullet. No typed tool covers rigid-body setup, baking or constraints, so the simulation runs through Blender Python; use the typed tools for everything they do reach. Native Blender is sufficient. When an optional fracture runtime is installed, locate its package and read the relevant operation contracts first — its generic fracture operations do not assemble a complete building. Report unavailable capabilities and proceed only through verified alternatives.
+
+This server drives a dedicated background Blender process and cannot see an open desktop window. When the user refers to a building they just opened on screen, that file is not the session's file: ask for its path and open it with `bl_open_project`. Save .blend files before disconnecting; unsaved state is lost on reconnect.
+
+Save a separate working version and preserve source geometry and manual edits. Keep physical fragments, structural connections, decorative geometry, and effects identifiable. Do not reset an unrelated scene or discard another unsaved project. For compatible revisions, reuse existing fragments and preserve object and mesh identities; retain names, ownership, and settings outside the requested change.
+
+## Route and execute
+
+For creating or changing geometry and connections, read [assembly and connections](references/assembly.md). For changing the trigger, tuning physics, recalculating, or diagnosing motion, read [simulation and acceptance](references/simulation.md). For saving calculations, adding effects, composing cameras, rendering, or delivering results, read [presentation and delivery](references/delivery.md). Load only the references required by the selected work.
+
+Establish intact stability before accepting collapse. Accept physical motion before deriving effects, and verify saved playback before delivery. Completion requires the requested failure scope, preserved inputs, usable calculation data, the requested preview, and an accurate account of prescribed motion and unresolved checks. Structural collapse, supported rubble, and complete rest are separate claims.

package/skills/blender-destruction/references/assembly.md

@@ -0,0 +1,23 @@
+# Assembly and Connections
+
+## Independent bodies and preserved sources
+
+Give every brick and glass shard claimed as independently simulated its own object and native rigid body. Shared mesh datablocks may reduce memory without coupling motion. Decorative subdivisions, parented children, and concealed animated carriers do not provide independent physics. Report physical counts separately from visible detail.
+
+Retain original panels, glazing, and structural components in hidden, identifiable collections. Rebuild only affected geometry and identify manual adjustments that would be lost. Transform shared mesh geometry once per datablock, or make it unique before object-specific edits.
+
+## Collision preparation
+
+Use closed fragments with finite coordinates, positive volume, and physically meaningful thickness. Form glazing from irregular planar cells extruded into closed solids. Derive mass from density and actual volume. Model visible steel sections explicitly while recognizing that convex hull collision envelopes may fill their voids.
+
+Check initial clearance around beams, masonry headers, glazing, and frame bars before increasing solver quality. Relate margins and gaps to the smallest physical thickness. Overlapping bounding boxes are broad-phase candidates, not proof of collision interference; refine them against the actual collision shapes. Batched environment meshes and irregular glass can have misleading bounds.
+
+Batch rigid-body registration when supported and confirm that every body and constraint belongs to the intended world. Copied constraints need independent settings and correct endpoints without duplicate registration. Cache topology checks per unique mesh and restrict contact searches spatially.
+
+## Load paths and connection roles
+
+Construct explicit load paths through foundations, columns, girders, slabs, masonry anchors, and glazing mounts. Treat mortar, facade ties, frame brackets, frame corners, glass seams, and structural steel as distinct connection groups. A stable core does not establish stable windows. Connect neighboring shards and frame corners where needed to retain intact glazing until failure.
+
+For unstable masonry with verified clearance, inspect missing support and local solver convergence. Additional breakable ties may connect masonry to actual same-level steel or slab surfaces. Their placement and strength must follow the current assembly; added stability can also create unintended support across a planned demolition cut.
+
+Blender breaking thresholds are constraint impulse limits, not calibrated material strengths in pressure units. Segmented steel with angular springs approximates flexing and separation, not continuum plastic deformation. Keep collision exclusions deliberate and local; broad suppression can conceal assembly defects.

package/skills/blender-destruction/references/delivery.md

@@ -0,0 +1,29 @@
+# Presentation and Delivery
+
+## Native calculation and evidence
+
+Keep prepared geometry and calculated presentation as separate versions. Blender has one active rigid-body world cache per scene. Use a distinct run destination and record the actual version and build, frame range and rate, solver settings, trigger schedule, body inventory, and cache representation.
+
+If an optional fracture runtime is driving the simulation, confirm that its world ownership and fragment inventory cover the entire intended assembly before choosing its bake operation. Do not fabricate ownership tags or discard a foreign world to bypass compatibility checks. For other native assemblies, preserve their world and use verified Blender controls to save its cache and record evaluated transforms for every relevant body.
+
+In the tested Blender 5.2 workflow, a complete sequential native calculation was frozen through bpy.ops.ptcache.bake_from_cache without a second simulation. Verify operator availability, supply the intended scene and point-cache context, and confirm complete cache coverage and baked state before adopting this path elsewhere. Avoid redundant writes to PointCache.use_disk_cache after saving: the inspected runtime records a crash from assigning an already-false value in its tested 5.2 build. Change cache mode only when needed, before calculation, and verify the running version's behavior.
+
+Stream evaluated transforms during large calculations, identify incomplete archives distinctly, and mark them complete only after the entire range succeeds. Keep only needed samples in memory for diagnosis. A transforms archive supports evidence and effects; it is not the solver cache. Do not claim external rigid-body cache files merely because a cache path was assigned.
+
+For an already baked scene without an archive, recover baseline poses from its existing native cache before editing and label the record as recovered evidence. Do not recalculate solely to fit a helper. Record enough file identity and settings to associate later checks with the actual accepted calculation.
+
+## Presentation without physical changes
+
+Add dust after accepting the motion. Derive its timing and location from measured masonry or concrete movement and deceleration, excluding glass and steel as dust emitters. These estimates are not native contact events. Distinguish authored cloud growth and drift from gas simulation, and replace owned effects without duplication.
+
+Frame the actual breakup, exposed steel, flying shards, and landing area. Inspect intact, onset, collapse, and aftermath renders before committing to the full sequence. Keep dust from masking unresolved support or failed collapse. Compare physical settings, geometry identities, evaluated poses, and baked state before and after presentation edits.
+
+Inspect glass in the selected renderer. Check material-level refraction and scene tracing capabilities instead of assuming a transmission value is sufficient. The tested Eevee configuration retained speckling even with more samples. A denoised Cycles render resolved it; disclosed alpha-blended glass without physical refraction was also usable for a fast preview. Treat that as a conditional rendering fallback, preserve the saved transmission material, and leave physics unchanged. Measure representative render times before committing to a renderer or parallel jobs.
+
+## Saved and encoded verification
+
+Reopen the exact final project in a separate Blender process with automatic script execution disabled. Compare evaluated poses for all physical bodies against the matching archive after nonsequential frame visits. Confirm baked state, source preservation, body inventory, and absence of unintended transform animation or parenting. Associate reports with file hashes; historical checks from another revision do not validate the delivered file. Repeat affected verification after later changes.
+
+When an animated preview is requested, render the complete range, encode it, and decode the finished movie fully. Check frame count, rate, dimensions, and duration, then inspect decoded images around onset, impact, and the ending. Encoding success alone is insufficient. Parallel jobs require disjoint frame ranges and separate progress records. Resume only frames known to belong to the same accepted project and render settings.
+
+Deliver usable links to the editable project, requested preview, and actual cache or an embedded-cache explanation. State what was simulated, prescribed, or approximated, which checks passed, and material limitations such as continuing settling or simplified preview glass. Preserve provenance and license notices when distributing reused runtime source. Open the project without discarding another unsaved scene.