Plan IWSDK features, architecture, and code patterns with best-practice guidance.
The material indicates this is an open-source prompt/planning guide skill with no required secrets and no declared remote endpoints, code execution, or data/file access. Overall risk is low based on the provided facts, with the main caution being low community adoption and unknown maintenance status as supply-chain uncertainty.
The material explicitly states that no keys or environment variables are required. There is no indication of requesting API tokens, account credentials, or sensitive local configuration, so credential exposure and abuse risk appears low.
The system flags it as prompt-only and no remote host endpoints are declared. The README content is architectural guidance and best practices, with no factual indication that user data is sent to external services.
Based on the material, this is a skill document for planning and code review guidance, with no stated ability to spawn local processes, execute scripts, or invoke system capabilities. The available evidence supports it being text-only guidance.
There is no declaration of reading or writing local files, databases, clipboard contents, or other user resources. The description focuses on IWSDK architectural patterns and implementation advice, with no sign of excessive data access.
A positive factor is that it comes from an open-source GitHub repository, making the source auditable. However, the repo has 0 stars, no declared license, and unknown maintenance status, so community validation and maintenance signals are weak and should be verified before adoption.
Copy the install command and let the AI configure it · recommended for beginners
Please install the "iwsdk-planner" skill from askskill: 1. Download https://raw.githubusercontent.com/facebook/immersive-web-sdk/main/.claude/skills/iwsdk-planner/SKILL.md 2. Save it as ~/.claude/skills/iwsdk-planner/SKILL.md 3. Reload skills and tell me it's ready
Create a technical plan for a new message sync feature in IWSDK. Explain module boundaries, ECS design, signal flow, reactive data handling, recommended best practices, and anti-patterns to avoid.
A structured feature architecture plan with component responsibilities, data flow, pattern recommendations, and risk notes.
Review this module architecture against existing IWSDK patterns. Focus on ECS boundaries, signal usage, reactive programming consistency, and compliance with project best practices.
An architecture review outlining issues, reasons, improvement suggestions, and alternative implementation approaches.
Summarize the core design patterns used in IWSDK for ECS, signals, and reactive programming. Explain use cases, pros and cons, and conventions to follow for new component development.
A developer-facing pattern guide that helps the team maintain consistent architecture in new development.
You are an expert IWSDK (Immersive Web SDK) architect. Apply these patterns and best practices when planning, implementing, or reviewing IWSDK code.
IWSDK is built on three pillars:
elics library@preact/signals-coreIWSDK is a 3D web framework with first-class XR support. World.create() always creates a persistent world.player origin and keeps world.camera under it, even when xr: false is used for browser-only apps. For first-person browser movement, move world.player; for orbit, editor, product, cinematic, or third-person cameras, it is fine to keep world.player at the origin and drive world.camera. Remember that world.camera.position is local to world.player, so use camera.getWorldPosition(...) when world-space viewer position matters.
Use input.canvasPointerEvents for browser mouse/touch canvas events. Browser canvas pointers and XR rays both feed Three/Object3D pointer events and ECS Hovered/Pressed tags on Interactable/RayInteractable entities. XR-specific input is available at world.input.xr; keyboard and standard browser gamepads live at world.input.keyboard and world.input.browserGamepads. Reusable systems should prefer world.input.actions for intent such as locomotion.move or locomotion.jump; opt into browser locomotion bindings with features.locomotion.browserControls.
Systems should NOT store arrays of entities or maintain entity references. Use queries instead.
// ❌ BAD - Storing entity references
export class BadSystem extends createSystem({
items: { required: [MyComponent] },
}) {
private myEntities: Entity[] = []; // DON'T DO THIS
init() {
this.queries.items.subscribe('qualify', (entity) => {
this.myEntities.push(entity); // BAD: manually tracking entities
});
}
}
// ✅ GOOD - Use queries for entity access
export class GoodSystem extends createSystem({
items: { required: [MyComponent] },
}) {
update() {
// Query always gives current matching entities
for (const entity of this.queries.items.entities) {
// Process entity
}
}
}
Exception: Scratch variables for temporary per-frame calculations are OK.
Instead of polling or storing state, react to entity lifecycle events:
export class ReactiveSystem extends createSystem({
interactables: { required: [Interactable, Transform] },
}) {
init() {
// React when entities enter the query
this.queries.interactables.subscribe('qualify', (entity) => {
this.setupEventListeners(entity);
});
// React when entities leave the query
this.queries.interactables.subscribe('disqualify', (entity) => {
this.cleanupEventListeners(entity);
});
}
}
IWSDK uses @preact/signals-core. Prefer signals over manual state tracking:
// System config properties are automatically signals
export class MySystem extends createSystem(
{},
{
speed: { type: Types.Float32, default: 5.0 },
jumpHeight: { type: Types.Float32, default: 2.0 },
},
) {
init() {
// Subscribe to config changes reactively
this.cleanupFuncs.push(
this.config.speed.subscribe((newSpeed) => {
console.log('Speed changed:', newSpeed);
}),
);
}
update(delta) {
// Read signal value with .peek() in update loops (no subscription overhead)
const currentSpeed = this.config.speed.peek();
}
}
Store signals in world.globals for state that multiple systems need to read/write:
// In index.ts (initialization)
import { signal } from '@preact/signals-core';
…
Build, debug, and refine IWSDK PanelUI panels more efficiently.
Test multiple grab interaction modes with the iwsdk CLI.
Test XR interactions, panels, and audio behavior with the iwsdk CLI.
Debug WebXR real-time behavior frame by frame with pause, snapshots, and diffs.
Implement depth sensing occlusion in IWSDK and troubleshoot rendering issues.
Test XR session lifecycle and mode transitions to verify behavior and debug state issues.
Create, modify, debug, and preview PanelUI components in IWSDK apps.
Implement physics simulation, interactions, and collision debugging in IWSDK projects.
Create objective-driven plans for agent-led development with an audit trail.
Test level hierarchy, tags, and lighting setup with the iwsdk CLI.
Test Havok physics behaviors with the iwsdk CLI against example scenes.
Turn requirements into a clear step-by-step execution plan before implementation.