Update to Claus Argos Skill OS

{
  "description": "Engineer approved interactive realtime 3D web experiences with Three.js, WebGL, WebGPU, or an equivalent browser rendering stack through representation proofs, composition and material checkpoints, runtime budgets, accessibility fallbacks, and perceptual review. Use when realtime 3D is a primary implementation medium. Do not use for static 3D asset creation alone, ordinary UI implementation, speculative visual direction, or read-only critique.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 280
    }
  ],
  "name": "engineer-realtime-3d-web-experiences",
  "skill_md_contents": "---\nname: engineer-realtime-3d-web-experiences\ndescription: Engineer approved interactive realtime 3D web experiences with Three.js, WebGL, WebGPU, or an equivalent browser rendering stack through representation proofs, composition and material checkpoints, runtime budgets, accessibility fallbacks, and perceptual review. Use when realtime 3D is a primary implementation medium. Do not use for static 3D asset creation alone, ordinary UI implementation, speculative visual direction, or read-only critique.\n---\n\n# Engineer Realtime 3D Web Experiences\n\nBuild a credible realtime experience from the best-known applicable method. Prove an open representation decision before committing; execute a closed method without restarting cross-method exploration, while still verifying its project-specific output, integration and calibration.\n\n## Mandatory representation gate\n\nRead the shared [representation strategy contract](../../shared/expert-system/representation-strategy-contract.md). Before detailed production, inspect the active method record under the shared decision-authority model.\n\nIf the method is `OPEN`:\n\n1. define target, importance, interaction, fidelity, screen impact, supported devices, runtime budget, and proof method;\n2. compare only viable representations such as procedural geometry, authored assets, textures, sprites, impostors, video, hybrid DOM/canvas, or non-3D alternatives that could materially change the decision;\n3. build the smallest hero or interaction proof that can fail honestly;\n4. inspect real output on representative hardware;\n5. obtain the required authorized method decision.\n\nIf the method is `METHOD_CLOSED`, confirm identity, continuing applicability and absence of a canonical reopen trigger, then execute it. Any production-candidate proof now targets unresolved implementation, integration or calibration questions inside that method—not whether CSS, raw WebGL, a different engine or another simpler representation might also work. Preserve and escalate an evidenced reopen trigger instead of switching methods silently.\n\nDo not encode an open, unproven representation into a final specification. Do not treat an applicable closed method as open merely to repeat technique selection.\n\nFor every material element, identify the observable, required views, real screen-space contribution, whether change is predefined or user-controlled, and why realtime is necessary. Treat authoring source, publishing target and runtime representation as separate when an asset pipeline is material. A source master may be created offline and publish optimized geometry, baked detail, textures, sprites, prerenders or other derivatives; do not force either offline authoring or runtime generation. Keep semantic content and ordinary browser interaction in the DOM unless the approved experience provides evidence for another representation.\n\n## Expert routing\n\nRoute from the shared [role registry](../../shared/expert-system/expert-role-registry.md). Typical lead is `TECHNICAL_ART_DIRECTOR` or `REALTIME_3D_WEB_ENGINEER`; support may include shader, asset, lookdev, material, lighting, camera/composition, frontend, accessibility, and GPU performance roles. Independent review includes creative direction and visual quality for critical visual gates.\n\nClassify choices using the shared [decision-authority model](../../shared/expert-system/decision-authority-model.md). Object identity, fundamental composition, brand direction, product behavior, performance-visible trade-offs, and representation changes that alter the target remain Class 1. Bounded topology, material, lighting, camera, and renderer refinements may be Class 2 when explicitly delegated.\n\n## Production sequence\n\n1. Composition shell and camera proof.\n2. Lighting and tonal-range proof.\n3. Hero asset and representation proof.\n4. Primary material and lookdev proof.\n5. Primary interaction and motion proof.\n6. Secondary assets and scene integration.\n7. Full responsive experience and DOM/canvas integration.\n8. Performance, fallback, accessibility, and release polish.\n\nApply the shared [visual checkpoint policy](../../shared/expert-system/visual-checkpoint-policy.md). At each applicable gate run a real local preview, capture comparable evidence, and stop before downstream production when composition, material credibility, lighting, motion, or performance fails.\n\nClassify proofs as throwaway exploration or production-candidate proofs. When an authorized real-output PASS establishes a calibration checkpoint, preserve its accepted parameters, assets, state, evidence and bounds without silent downstream drift. Use an optional controlled reference visual oracle for material-, form- or surface-critical work only; it guides art/material perception and does not become automatic browser pixel truth.\n\n## Causal diagnostic fork\n\nBefore tuning a failed visual/3D gate, classify the evidenced cause as COMPOSITION_CAMERA, REPRESENTATION, GEOMETRY, NORMALS_TANGENTS, MATERIAL, LIGHTING, REFLECTION_ENVIRONMENT, MOTION, RENDERER, TONEMAPPING_COLOR, PERFORMANCE, MEASUREMENT_QA, MIXED or INCONCLUSIVE.\n\nDo not automatically change the most visible parameter. Poor metal readability is not automatically a lighting defect; geometry or normal distribution may be unable to carry the required reflections. Use the smallest diagnostic that can distinguish causal layers. Temporary changes must be isolated, reversible, restored and restore-verified. Preserve INCONCLUSIVE when evidence cannot establish cause, and route representation/root-cause review instead of inventing certainty or repeating microcalibration.\n\n## Runtime and quality contract\n\nDefine and measure frame-time or responsiveness targets, draw calls, triangles or geometry complexity where useful, textures and memory, shader compilation, loading and streaming, resize behavior, input handling, disposal, context loss, reduced motion, keyboard or alternative interaction, and non-3D fallback. Numbers are `FIXED` only when supported; otherwise use targets, bounds, calibration, or runtime verification.\n\nUse desktop, mobile, low-capability, reduced-motion or non-3D publishing tiers only when the project evidence needs them. They may vary texture size, geometry, shadows, DPR caps, effects, preloading and asset detail while preserving the approved product experience and visible bounds; do not build a generic tier engine by default.\n\nDetermine whether continuous rendering is required. When the architecture and visual behavior support it, distinguish active interaction or cinematic motion from resting, offscreen and hidden-tab states and reduce or suspend work accordingly. Account for continuity-dependent animation. Measure first-contact risks such as shader compilation, texture upload, asset decode, first scene entry and first interaction; precompile, prewarm, prefetch or preload neighboring state only when evidence justifies the cost.\n\nIf repeated lookdev is blocked by edit/restart/screenshot guessing, a small project-specific runtime preset surface may expose only repeatedly calibrated production parameters such as exposure, environment, material roughness, light intensity or normal strength. It must use the real production values, lock owner/FIXED values and remain an internal aid—not a generic editor or new product. Prefer ordinary preview, CSS variables or developer tools when sufficient.\n\nApply the shared [risk-adaptive assurance model](../../shared/expert-system/risk-adaptive-assurance-model.md). Use a controlled acceptance environment only when runtime identity or reproducibility materially affects the gate; do not turn project-specific 3D assurance into universal infrastructure.\n\nTechnical and perceptual gates are independent. A stable frame rate does not prove visual quality, and a beautiful frame does not excuse instability, inaccessibility, or excessive resource use. The builder may report and self-test but cannot finally ratify a material visual gate; keep the authority checkpoint separate from the candidate and obtain owner review when the contract requires it.\n\nEvery nontrivial effect must improve an approved observable such as perception, spatial credibility, feedback, orientation, storytelling, brand authorship, materiality or product understanding. When material complexity creates a documented clarity, performance or authorship risk, a bounded subtraction review may be selected before final visual approval; if selected, remove only unjustified effects or machinery.\n\n## Output\n\nReturn the implemented experience, approved representation and proofs, task contract, checkpoint evidence, causal classification and diagnostics, runtime measurements, Class-2 decision log, browser/device results, fallback behavior, independent review, regressions, rollback, and residual risks.\n"
}