Debug continuous behavior in WebXR scenes — physics, animations, collisions, game loops, or any real-time interaction that happens too fast for an agent to observe. Uses ECS pause/step/snapshot/diff to freeze time and inspect state frame by frame.
npx skills add https://github.com/facebook/immersive-web-sdk --skill iwsdk-debug
Real-time behavior (physics, animations, collisions, game loops) happens too fast for an agent to observe directly. By the time you take a screenshot, the action is over. This skill uses ECS time-control tools to freeze, step, and diff state frame by frame.
User request is in $ARGUMENTS.
Every debugging session follows this pattern:
ecs_pause — freeze ECS updates right before the interesting momentecs_snapshot({ "label": "before" }) — capture state before the actionecs_step(count, delta) — advance a few frames at fixed timestepbrowser_screenshot — visually verify what happenedecs_snapshot({ "label": "after" }) — capture state after steppingecs_diff({ "from": "before", "to": "after" }) — see exactly what changed10. ecs_resume — return to normal execution when done
The key insight: pause BEFORE triggering the action, not after. If you pause after, you've already missed the first frames.
| Tool | Purpose |
| ------------------------------------------------- | ------------------------------------------------------------------------------------ |
| ecs_pause | Freeze all ECS system updates. Render loop continues — screenshots still work. |
| ecs_step({"count":N,"delta":SECONDS}) | Advance N frames with fixed timestep (seconds). Must pause first. |
| ecs_resume | Resume normal execution. First frame uses capped delta to avoid physics explosions. |
| ecs_snapshot({"label":"..."}) | Capture full ECS state. Stores up to 2 snapshots. |
| ecs_diff({"from":"...","to":"..."}) | Compare two snapshots. Shows added/removed entities and field-level value changes. |
| ecs_toggle_system({"name":"...","paused":true}) | Pause/resume a single system. Use ecs_list_systems to discover names. |
| browser_screenshot | Runtime visual verification — works while paused and auto-switches from editor view. |
delta is in seconds. Common values: 0.016 (60fps), 0.0139 (72fps/Quest refresh rate).Short domain-specific tips. Apply the core workflow above, plus these hints.
delta: 0.016 to catch initial acceleration.PhysicsBody._linearVelocity and PhysicsBody._angularVelocity to see motion direction and speed.Transform.position to track movement.PhysicsBody (Static) and PhysicsShape (TriMesh for complex geometry).ecs_query_entity to inspect PhysicsShape and PhysicsBody on both the falling object and the surface.PhysicsBody._linearVelocity shows the throw direction and speed.PhysicsBody with state: Dynamic.delta matching your target framerate.Transform.position, Transform.orientation, and Transform.scale across snapshots to track interpolation.PhysicsBody._linearVelocity sign changes (indicates bounce/impact).PhysicsBody._angularVelocity spikes (indicates tumbling from impact).PhysicsShape exists on both entities, and verify shape types are appropriate (use TriMesh for complex static geometry).ecs_list_systems to see all systems and their priorities.ecs_toggle_system({ "name": "SystemName", "paused": true }) to pause a suspect system while others run.ecs_step will fail if you haven't called ecs_pause first.Create a narrated video walkthrough of a pull request with code slides and audio narration. Use when asked to create a PR walkthrough, PR video, or walkthrough video.
Design the small details -- triggers, rules, feedback, loops and modes -- that separate good products from great ones. Use when the user mentions "microinteraction", "button feedback", "loading state", "toggle design", "animation detail", "state transitions", "input feedback", "the interface feels dead", "make the UI feel responsive", or "add polish to interactions". Also trigger when designing form-validation responses, progress indicators, confirmation dialogs, or any element where the user expects immediate feedback. Covers trigger design, state rules, feedback mechanisms, and progressive loops. For overall UI polish, see refactoring-ui. For affordance design, see design-everyday-things.
Profile, diagnose, and remediate SwiftUI runtime performance using code review, Instruments, and repeatable measurements. Use when a SwiftUI screen renders slowly, scrolling or animations hitch, view bodies update excessively, list identity churns, layout work spikes, or broad Observation dependencies raise CPU cost. Covers evidence-based triage, SwiftUI Instruments lanes, lazy-container guardrails, state lifetime, and before/after verification.
Turn a GitHub pull request (a PR URL, owner/repo#N, or 'this PR' in a checked-out repo) into a code-change explainer video — changelog, feature reveal, fix, or refactor walkthrough built from the diff, commits, and files: the input is a code change, not a website. Not a product promo (/product-launch-video) or a no-PR topic explainer (/faceless-explainer). Unclear → /hyperframes.
Use when writing, reviewing, or refactoring SwiftUI code for iOS or macOS, including state management and `@Observable` data flow, view composition and invalidation/performance, lists and `ForEach` identity, environment usage, localization, animations, Liquid Glass adoption, migrating...
Turn a GitHub pull request (a PR URL, owner/repo#N, or 'this PR' in a checked-out repo) into a code-change explainer video — changelog, feature reveal, fix, or refactor walkthrough built from the diff, commits, and files: the input is a code change, not a website. Not a product promo (/product-launch-video) or a no-PR topic explainer (/faceless-explainer). Unclear → /hyperframes.
Audit creative release folders before handoff: metadata, file structure, artwork, lyrics, stems, rights blockers, and platform readiness.
Load when existing animation or motion code, a motion diff, or a rendered interaction needs an evidence-backed craft review; report findings only and use code-review for general source review.
Take facebook/iwsdk-debug from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.