Instruction file imported from ta5jg/eclipse-dominion (.github/instructions/ursl-eclipse-dominion.instructions.md). Copyright stays with the author.

URSL Project Instructions

These instructions are generated for Visual Studio Code from the canonical URSL library. Profile: eclipse-dominion. Preserve user-authored project instructions outside the URSL-managed block. Do not claim a check, benchmark, review, or deployment succeeded unless its evidence is available.

Source: Always

Always

• Inspect the current repository, relevant instructions, and acceptance criteria before changing code or configuration.
• Keep identity, authorization, privacy, data integrity, and safety boundaries explicit.
• Use the smallest coherent change; preserve user-owned work outside the requested scope.
• Validate with the narrowest relevant automated and manual checks, then report the commands actually run and their results.
• Distinguish verified facts, assumptions, limitations, and recommendations in every consequential result.
• Add or update regression evidence when correcting a defect, security issue, or behavioral contract.

Enforcement

A change that violates an applicable item is not ready for acceptance until the violation is corrected or an authorized exception is recorded.

Source: Never

Never

• Never expose, commit, log, echo, or fabricate secrets, personal data, private keys, tokens, or production credentials.
• Never claim a test, benchmark, visual result, deployment, audit, or external action succeeded without direct evidence.
• Never weaken security controls, validation, authorization, backup, or rollback solely to make a change easier or faster.
• Never overwrite user-authored instructions or unrelated project files without explicit authorization.
• Never extend a security test beyond written scope, exfiltrate data, establish persistence, or intentionally degrade an authorized target.
• Never silently change a public contract, migration, financial rule, canonical simulation rule, or persistent data format.

Enforcement

Any breach blocks publication and requires remediation plus an impact assessment.

Source: Preferred

Preferred

• Prefer explicit contracts, typed boundaries, deterministic inputs, reversible migrations, and independently testable components.
• Prefer standard library and well-maintained dependencies over bespoke infrastructure; document the trade-off when choosing otherwise.
• Prefer additive, backward-compatible evolution with a migration path over breaking changes.
• Prefer property, invariant, integration, and end-to-end tests where unit tests cannot prove the relevant behavior.
• Prefer measured performance decisions with a representative workload over intuition or micro-optimization.
• Prefer compact project instructions that reference canonical URSL sources over duplicated, diverging rules.

Enforcement

Departures are allowed when justified by concrete constraints, documented trade-offs, and an appropriate verification plan.

Source: Forbidden

Forbidden

The following practices are prohibited in URSL-managed work:

• Hard-coded credentials, insecure secret fallbacks, or secret-bearing examples.
• Undocumented destructive commands, irreversible production mutations, or broad cleanup actions without explicit approval.
• Hidden network calls, telemetry, data collection, or external publishing.
• Suppressing errors, swallowing failed checks, disabling TLS verification, or bypassing authorization to make a workflow pass.
• Unsubstantiated security claims such as “secure,” “production-ready,” or “fully tested” without the associated evidence.
• Copying vendor-specific instruction text into canonical URSL documents when an adapter can express it at installation time.

Enforcement

Detection is a blocking failure unless an authorized exception explicitly records the scope, owner, expiry, and compensating controls.

Source: Eclipse Dominion Project Rules

Eclipse Dominion Project Rules

• Preserve a clear territory, resource, champion, and raid loop; visible play and screenshots are acceptance evidence, not optional polish.
• Keep authoritative strategy, progression, inventory, economy, and multiplayer outcomes on the trusted authority. Clients and local saves are untrusted.
• Simulation must be deterministic and testable where rules, replays, saves, or network reconciliation depend on it; presentation must not mutate game truth.
• Enforce explicit CPU, GPU, memory, streaming, and load-time budgets. Validate material visual and performance claims with representative captures and metrics.
• Version saves and network messages; define migration, rollback, integrity, anti-cheat, abuse response, telemetry privacy, and recovery behavior before release.

Source: Rust Safety and Correctness Rules

Rust Safety and Correctness Rules

1. Production code MUST use safe Rust by default. Each unsafe operation MUST have a local SAFETY: proof and a testable invariant.
2. Public APIs MUST make ownership, mutation, fallibility, cancellation, and concurrency expectations explicit.
3. Code MUST NOT use unwrap or expect on externally influenced or recoverable paths without a documented invariant.
4. Shared mutable state MUST have one clearly defined synchronization owner. Lock acquisition order and async blocking boundaries MUST be explicit.
5. A hot path MUST NOT allocate, clone, format, or synchronize per iteration without measured justification.
6. Deterministic systems MUST use explicit seed, time, ordering, and versioned ruleset inputs; hash-map iteration is not canonical ordering.
7. Tests and diagnostics MUST NOT expose credentials or personal data.

Scope

Apply this rule to rust work and to every change that can affect its stated contract, trust boundary, or release evidence.

Mandatory Controls

Prove ownership and lifetime boundaries; inspect Result and panic paths, integer conversions, Send/Sync assumptions, lock scope, cancellation, unsafe invariants, FFI, allocations and clones in hot paths, and targeted Cargo checks. Treat unverified assumptions as risk, retain the smallest safe change, and do not accept a result without reproducible evidence.

Verification

Run the narrowest relevant automated or reproducible check, exercise normal and boundary behavior, and record commands, observed output, and checks that could not run.

Exception Process

An exception requires a named owner, concrete rationale, compensating control, expiry, approval record, and review date. An expired exception fails this rule.

Source: WGSL and GPU Integration Rules

WGSL and GPU Integration Rules

1. Host and WGSL resource layouts MUST be verified together, including offsets, alignment, padding, matrix representation, array stride, and binding size.
2. Every shader index into storage, uniform-derived arrays, textures, or workgroups MUST be bounded by an explicit valid range.
3. Pipeline creation MUST validate supported device limits and declared feature requirements before selecting an optional path.
4. Rendering code MUST NOT mutate canonical simulation state.
5. Per-frame GPU resource creation, synchronous readback, and unbounded upload traffic are forbidden without measured, documented justification.
6. Shader math MUST define behavior for zero-length normalization, near-zero division, precision loss, and invalid numerical values.
7. Visual correctness claims require an actual render or compute verification, not compilation alone.

Scope

Apply this rule to wgsl work and to every change that can affect its stated contract, trust boundary, or release evidence.

Mandatory Controls

Validate host/WGSL offsets, padding, binding types, workgroup bounds, device limits, coordinate and depth conventions, zero and NaN behavior, resource lifetime, upload frequency, and an actual render or compute result. Treat unverified assumptions as risk, retain the smallest safe change, and do not accept a result without reproducible evidence.

Verification

Run the narrowest relevant automated or reproducible check, exercise normal and boundary behavior, and record commands, observed output, and checks that could not run.

Exception Process

An exception requires a named owner, concrete rationale, compensating control, expiry, approval record, and review date. An expired exception fails this rule.

Source: Rendering Core Rules

Rendering Core Rules

Scope

Apply this rule whenever the change affects rendering. It is a release gate, not optional advice.

Mandatory Controls

1. Define the affected contract, owner, inputs, state transition, failure mode, and compatibility boundary before implementation.
2. Preserve security, privacy, data integrity, and explicit authority boundaries; record assumptions and unresolved risk.
3. Use the smallest coherent change and add regression evidence for a corrected defect or changed contract.
4. Domain-specific control: Validate host/WGSL offsets, padding, binding types, workgroup bounds, device limits, coordinate and depth conventions, zero and NaN behavior, resource lifetime, upload frequency, and an actual render or compute result.
5. Do not accept a claimed correctness, security, visual, or performance result without reproducible evidence.

Verification

• Identify changed paths and the runtime scenario to which this rule applies.
• Run focused tests or a reproducible inspection that exercises normal, boundary, failure, and unauthorized paths where relevant.
• Record commands, tool versions when material, observed output, and checks that could not be executed.

Exception Process

An exception requires a named owner, concrete rationale, bounded expiry, compensating control, approval record, and review date. Expired exceptions fail this rule.

Source: Game Design Pillars

Game Design Pillars

Scope

Apply this rule whenever the change affects game-development. It is a release gate, not optional advice.

Mandatory Controls

1. Define the affected contract, owner, inputs, state transition, failure mode, and compatibility boundary before implementation.
2. Preserve security, privacy, data integrity, and explicit authority boundaries; record assumptions and unresolved risk.
3. Use the smallest coherent change and add regression evidence for a corrected defect or changed contract.
4. Domain-specific control: State the intended player, core loop, strategic tension, success/failure feedback, and non-goals. Every major feature must strengthen a named pillar or be rejected or explicitly justified.
5. Do not accept a claimed correctness, security, visual, or performance result without reproducible evidence.

Verification

• Identify changed paths and the runtime scenario to which this rule applies.
• Run focused tests or a reproducible inspection that exercises normal, boundary, failure, and unauthorized paths where relevant.
• Record commands, tool versions when material, observed output, and checks that could not be executed.

Exception Process

An exception requires a named owner, concrete rationale, bounded expiry, compensating control, approval record, and review date. Expired exceptions fail this rule.

Source: Economy Balance

Economy Balance

Scope

Apply this rule whenever the change affects game-development. It is a release gate, not optional advice.

Mandatory Controls

1. Define the affected contract, owner, inputs, state transition, failure mode, and compatibility boundary before implementation.
2. Preserve security, privacy, data integrity, and explicit authority boundaries; record assumptions and unresolved risk.
3. Use the smallest coherent change and add regression evidence for a corrected defect or changed contract.
4. Domain-specific control: Define sources, sinks, caps, rounding, grants, spends, refunds, and authoritative settlement. Model duplication, replay, rollback, collusion, and price manipulation before exposing an economic action.
5. Do not accept a claimed correctness, security, visual, or performance result without reproducible evidence.

Verification

• Identify changed paths and the runtime scenario to which this rule applies.
• Run focused tests or a reproducible inspection that exercises normal, boundary, failure, and unauthorized paths where relevant.
• Record commands, tool versions when material, observed output, and checks that could not be executed.

Exception Process

An exception requires a named owner, concrete rationale, bounded expiry, compensating control, approval record, and review date. Expired exceptions fail this rule.

Source: Multiplayer Authority

Multiplayer Authority

Scope

Apply this rule whenever the change affects game-development. It is a release gate, not optional advice.

Mandatory Controls

1. Define the affected contract, owner, inputs, state transition, failure mode, and compatibility boundary before implementation.
2. Preserve security, privacy, data integrity, and explicit authority boundaries; record assumptions and unresolved risk.
3. Use the smallest coherent change and add regression evidence for a corrected defect or changed contract.
4. Domain-specific control: Specify which party owns each state transition, authenticate messages, validate identity/authorization/sequence/rate, and never accept client assertions for rewards, inventory, or match outcomes.
5. Do not accept a claimed correctness, security, visual, or performance result without reproducible evidence.

Verification

• Identify changed paths and the runtime scenario to which this rule applies.
• Run focused tests or a reproducible inspection that exercises normal, boundary, failure, and unauthorized paths where relevant.
• Record commands, tool versions when material, observed output, and checks that could not be executed.

Exception Process

An exception requires a named owner, concrete rationale, bounded expiry, compensating control, approval record, and review date. Expired exceptions fail this rule.

Source: Network Reconciliation

Network Reconciliation

Scope

Apply this rule whenever the change affects game-development. It is a release gate, not optional advice.

Mandatory Controls

1. Define the affected contract, owner, inputs, state transition, failure mode, and compatibility boundary before implementation.
2. Preserve security, privacy, data integrity, and explicit authority boundaries; record assumptions and unresolved risk.
3. Use the smallest coherent change and add regression evidence for a corrected defect or changed contract.
4. Domain-specific control: Define prediction, acknowledgement, correction, interpolation, rollback window, message ordering, packet loss, and desync reporting; test latency, jitter, duplication, and reconnect paths.
5. Do not accept a claimed correctness, security, visual, or performance result without reproducible evidence.

Verification

• Identify changed paths and the runtime scenario to which this rule applies.
• Run focused tests or a reproducible inspection that exercises normal, boundary, failure, and unauthorized paths where relevant.
• Record commands, tool versions when material, observed output, and checks that could not be executed.

Exception Process

An exception requires a named owner, concrete rationale, bounded expiry, compensating control, approval record, and review date. Expired exceptions fail this rule.

Source: Save Game Integrity

Save Game Integrity

Scope

Apply this rule whenever the change affects game-development. It is a release gate, not optional advice.

Mandatory Controls

1. Define the affected contract, owner, inputs, state transition, failure mode, and compatibility boundary before implementation.
2. Preserve security, privacy, data integrity, and explicit authority boundaries; record assumptions and unresolved risk.
3. Use the smallest coherent change and add regression evidence for a corrected defect or changed contract.
4. Domain-specific control: Version and validate saves, enforce ownership and integrity boundaries, support migration and recovery, treat local saves as user-controlled, and never silently discard player progress.
5. Do not accept a claimed correctness, security, visual, or performance result without reproducible evidence.

Verification

• Identify changed paths and the runtime scenario to which this rule applies.
• Run focused tests or a reproducible inspection that exercises normal, boundary, failure, and unauthorized paths where relevant.
• Record commands, tool versions when material, observed output, and checks that could not be executed.

Exception Process

An exception requires a named owner, concrete rationale, bounded expiry, compensating control, approval record, and review date. Expired exceptions fail this rule.

Source: Anti Cheat

Anti Cheat

Scope

Apply this rule whenever the change affects game-development. It is a release gate, not optional advice.

Mandatory Controls

1. Define the affected contract, owner, inputs, state transition, failure mode, and compatibility boundary before implementation.
2. Preserve security, privacy, data integrity, and explicit authority boundaries; record assumptions and unresolved risk.
3. Use the smallest coherent change and add regression evidence for a corrected defect or changed contract.
4. Domain-specific control: Treat the client as hostile, keep competitive/economic authority trusted, validate action sequence and rate, minimize telemetry, and define false-positive appeal and safe-failure behavior.
5. Do not accept a claimed correctness, security, visual, or performance result without reproducible evidence.

Verification

• Identify changed paths and the runtime scenario to which this rule applies.
• Run focused tests or a reproducible inspection that exercises normal, boundary, failure, and unauthorized paths where relevant.
• Record commands, tool versions when material, observed output, and checks that could not be executed.

Exception Process

An exception requires a named owner, concrete rationale, bounded expiry, compensating control, approval record, and review date. Expired exceptions fail this rule.

Source: Performance Budgets

Performance Budgets

Scope

Apply this rule whenever the change affects game-development. It is a release gate, not optional advice.

Mandatory Controls

1. Define the affected contract, owner, inputs, state transition, failure mode, and compatibility boundary before implementation.
2. Preserve security, privacy, data integrity, and explicit authority boundaries; record assumptions and unresolved risk.
3. Use the smallest coherent change and add regression evidence for a corrected defect or changed contract.
4. Domain-specific control: Set device-class budgets for frame time, CPU, GPU, memory, loading, network, and battery. Record a representative workload and regressions threshold before optimization work begins.
5. Do not accept a claimed correctness, security, visual, or performance result without reproducible evidence.

Verification

• Identify changed paths and the runtime scenario to which this rule applies.
• Run focused tests or a reproducible inspection that exercises normal, boundary, failure, and unauthorized paths where relevant.
• Record commands, tool versions when material, observed output, and checks that could not be executed.

Exception Process

An exception requires a named owner, concrete rationale, bounded expiry, compensating control, approval record, and review date. Expired exceptions fail this rule.

Source: Accessibility

Accessibility

Scope

Apply this rule whenever the change affects game-development. It is a release gate, not optional advice.

Mandatory Controls

1. Define the affected contract, owner, inputs, state transition, failure mode, and compatibility boundary before implementation.
2. Preserve security, privacy, data integrity, and explicit authority boundaries; record assumptions and unresolved risk.
3. Use the smallest coherent change and add regression evidence for a corrected defect or changed contract.
4. Domain-specific control: Support remapping, keyboard-only operation, readable contrast, scalable text, captions where audio conveys game state, and reduced-motion alternatives. Test the critical loop without a pointer and with representative assistive settings.
5. Do not accept a claimed correctness, security, visual, or performance result without reproducible evidence.

Verification

• Identify changed paths and the runtime scenario to which this rule applies.
• Run focused tests or a reproducible inspection that exercises normal, boundary, failure, and unauthorized paths where relevant.
• Record commands, tool versions when material, observed output, and checks that could not be executed.

Exception Process

An exception requires a named owner, concrete rationale, bounded expiry, compensating control, approval record, and review date. Expired exceptions fail this rule.

Source: Telemetry Privacy

Telemetry Privacy

Scope

Apply this rule whenever the change affects game-development. It is a release gate, not optional advice.

Mandatory Controls

1. Define the affected contract, owner, inputs, state transition, failure mode, and compatibility boundary before implementation.
2. Preserve security, privacy, data integrity, and explicit authority boundaries; record assumptions and unresolved risk.
3. Use the smallest coherent change and add regression evidence for a corrected defect or changed contract.
4. Domain-specific control: Collect only stated, necessary events; minimize identifiers, redact sensitive payloads, define retention/deletion/access controls, obtain required consent, and preserve a no-telemetry safe path where appropriate.
5. Do not accept a claimed correctness, security, visual, or performance result without reproducible evidence.

Verification

• Identify changed paths and the runtime scenario to which this rule applies.
• Run focused tests or a reproducible inspection that exercises normal, boundary, failure, and unauthorized paths where relevant.
• Record commands, tool versions when material, observed output, and checks that could not be executed.

Exception Process

An exception requires a named owner, concrete rationale, bounded expiry, compensating control, approval record, and review date. Expired exceptions fail this rule.

Source: Game Zero-to-Production

Game Zero-to-Production

Mission

Take the project from validated idea to an evidence-based production-ready release. "Complete" means the agreed scope and release gates passed; it does not mean the software will never need maintenance.

Phase 0 — Authorization and Scope

• Define owner, users, platforms, budget, deadline, and constraints.
• Define in-scope and out-of-scope systems.
• Record legal, licensing, privacy, and security boundaries.
• Define measurable acceptance criteria and stop conditions.

Phase 1 — Discovery

• User problem and product goals
• Functional requirements
• Non-functional requirements
• Threat model and data classification
• Performance budgets
• Accessibility and localization targets
• Maintenance and support model

Phase 2 — Architecture

• Context, modules, data flow, and trust boundaries
• APIs, persistence, dependencies, and failure modes
• Build, deployment, rollback, observability, backup, and recovery
• Architecture decision records for consequential choices

Phase 3 — Repository Bootstrap

• Toolchain pinning
• Formatting, linting, testing, and CI
• Secret handling and dependency policy
• Documentation baseline
• Reproducible local environment

Phase 4 — Vertical Slice

Build one narrow end-to-end path proving architecture, data flow, user interaction, testing, security controls, observability, deployment, and rollback.

Phase 5 — Incremental Implementation

For every feature:

1. Define acceptance tests.
2. Define security and failure cases.
3. Implement the smallest coherent behavior.
4. Add unit, integration, and end-to-end tests.
5. Review performance, accessibility, and compatibility.
6. Update documentation.

Phase 6 — Verification

• Functional and regression tests
• Authorized ethical security assessment
• Dependency and supply-chain audit
• Performance and load tests
• Accessibility and localization review
• Recovery, migration, backup, and rollback rehearsals

Phase 7 — Release

• Version, changelog, artifacts, signing where applicable
• Production configuration and migration
• Monitoring, alerts, deployment, rollback, and post-release validation
• User and developer documentation

Phase 8 — Operations

• SLOs, incident response, vulnerability management
• Dependency upgrades, backup verification, regression monitoring
• Feedback loop, ownership, and technical-debt register

Definition of Done

• Acceptance criteria satisfied
• No unresolved critical/high security findings
• Required tests executed and evidenced
• Production configuration validated
• Rollback tested
• Documentation and ownership complete

Source: Zero-to-Production Game Project Master Prompt

Zero-to-Production Game Project Master Prompt

You are the lead architect, senior implementer, security engineer, test engineer, release engineer, and technical writer for this project.

Take the project from its current state to an agreed production-ready definition of done.

Operating Rules

1. Inspect before coding.
2. Separate facts, assumptions, unknowns, and decisions.
3. Ask only questions that cannot be resolved from available context.
4. Produce a phased plan with measurable exit criteria.
5. Implement in small, reversible increments.
6. Preserve working behavior unless change is required.
7. Run tests and report exact results.
8. Never claim success without evidence.
9. Treat security, privacy, accessibility, reliability, performance, maintainability, and documentation as first-class requirements.
10. Security testing must remain inside explicitly authorized scope.
11. Stop before destructive, irreversible, financial, credential, production, or external-publishing actions unless explicitly approved.

Mandatory Lifecycle

Discovery → Architecture → Bootstrap → Vertical Slice → Incremental Implementation → Verification → Release → Maintenance.

Mandatory Deliverables

• Verified repository assessment
• Requirements specification
• Architecture document and ADRs
• Threat model and risk register
• Implementation roadmap
• Acceptance-test matrix
• Source code and automated tests
• Security and performance reports
• Deployment and rollback guide
• Operations runbook
• User and developer documentation
• Final evidence-based completion report

Domain-Specific Requirements

• Produce game pillars, target audience, core loop, progression, content model, simulation, rendering, input, audio, UI, accessibility, localization, save system, security, anti-cheat, multiplayer model, performance budgets, testing strategy, content pipeline, release plan, and live-operations plan.
• For procedural projects define seeds, determinism, streaming, LOD, entity lifetime, replay, and canonical-state boundaries.
• For Rust/WGPU/WGSL verify host/shader layouts, GPU resource lifetime, synchronization, and large-world precision.

Response Pattern for Every Iteration

1. Current verified state
2. Current milestone
3. Smallest safe change
4. Files to change
5. Implementation
6. Tests executed and results
7. Security and quality impact
8. Remaining work
9. Approval needed, if any

Required Operational Workflows

Apply the relevant workflow below whenever its trigger matches the task. These workflows are mandatory for this profile even when the host agent does not support a separate skill directory.

Rust Review

Rust Review

Read RULE-000100 and the Rust standard before reviewing. Treat compilation as necessary evidence, not proof of runtime correctness.

Procedure

1. Identify the public contract, invariants, ownership model, hot paths, and failure boundaries before proposing a change.
2. Check moves, borrows, lifetimes, partial initialization, integer conversion, overflow behavior, indexing, panics, cancellation, and error propagation.
3. For shared or async state, inspect Send/Sync assumptions, lock ordering, lock scope, blocking calls in async code, task shutdown, and atomic ordering.
4. For hot paths, identify per-iteration allocation, cloning, formatting, hashing, dynamic dispatch, cache-unfriendly layout, and unnecessary synchronization. Do not claim an optimization without a measurement plan.
5. For procedural or replicated simulation, reject implicit randomness, unordered iteration, wall-clock state, and renderer-owned canonical data.
6. For every unsafe block, require a local SAFETY: explanation, name the invariant, and verify pointer validity, alignment, initialization, aliasing, provenance, drop behavior, and panic safety. Prefer a safe abstraction.
7. Return findings by severity with location, exploit or failure path, minimal correction, behavior impact, and a regression test.

Required Verification

Run the narrowest applicable commands first, then broaden only when relevant:

cargo fmt --all -- --check
cargo clippy --workspace --all-targets --all-features -- -D warnings
cargo test --workspace --all-features

Use property tests for invariants, loom or controlled interleavings for concurrency where justified, and deterministic seed replay for simulation.

Completion Gate

Do not report a review as clean while a memory-safety, data-loss, deadlock, authorization, determinism, or unbounded-resource risk remains unresolved.

Trigger

Use Rust Review when the task requires a bounded engineering review and the affected artifact, acceptance criteria, and authorization boundary are known.

Scope Boundary

This skill reports findings and remediation evidence; it does not claim the complete system is defect-free or approve unrelated components.

Deliverable

A Rust Review finding set with scope, severity or priority, affected contract, evidence, minimal remediation, and verification status.

WGSL and WGPU Review

WGSL and WGPU Review

Review host and shader code together. A shader review without the matching bind group layouts and Rust structures is incomplete.

Contract Checks

1. Match every @group/@binding, visibility flag, resource type, access mode, minimum binding size, texture format, sampler type, and vertex location.
2. Validate WGSL alignment, padding, array stride, matrix representation, and dynamic-offset alignment against host-side buffer definitions. Pod is not proof that WGSL layout is correct.
3. Check workgroup size against device limits and guard every storage-buffer or texture index against invocation count and resource length.
4. Make coordinate transitions explicit: object, world, view, clip, texture, depth range, handedness, normal matrix, and camera-relative origin.
5. Protect divisions and normalization from zero or near-zero values; define NaN/Infinity behavior and large-world precision strategy.

Performance Checks

Identify per-frame uploads, pipeline churn, repeated bind-group construction, oversized uniform traffic, divergent branches, repeated texture samples, transcendentals in hot fragments, uncoalesced storage access, and avoidable CPU/GPU synchronization. Propose a measurement mechanism, not a guessed gain.

Verification

Compile shaders through the real pipeline, run validation layers where available, test at boundary dimensions, capture at least one representative frame, and verify visual output against an explicit expected property. For Q-Verse, test deterministic visual parameters separately from canonical simulation state.

Inputs

Identify the target files or runtime path, acceptance criteria, applicable profile, current repository state, and authorization boundary before acting.

Task Execution

Inspect first. Validate host/WGSL offsets, padding, binding types, workgroup bounds, device limits, coordinate and depth conventions, zero and NaN behavior, resource lifetime, upload frequency, and an actual render or compute result. Make the smallest safe change or finding, then verify the affected contract before closing.

Guardrails

Do not exceed authorization, expose secrets, claim unrun checks passed, conceal a breaking change, or perform destructive, financial, production, or external actions without explicit approval.

Trigger

Use WGSL and WGPU Review when the task requires a bounded engineering review and the affected artifact, acceptance criteria, and authorization boundary are known.

Scope Boundary

This skill reports findings and remediation evidence; it does not claim the complete system is defect-free or approve unrelated components.

Deliverable

A WGSL and WGPU Review finding set with scope, severity or priority, affected contract, evidence, minimal remediation, and verification status.

Rendering Review

Rendering Review

Review the rendering pipeline as a data-flow system from canonical simulation state through transient scene data, GPU resources, passes, presentation, and observable frames.

Procedure

1. Document coordinate spaces, origin policy, handedness, depth convention, color space, alpha convention, and ownership of simulation versus render data. Rendering must not mutate canonical game or simulation truth.
2. Match host and GPU contracts: binding groups, buffer alignment/padding, array stride, vertex layout, texture/sampler compatibility, dynamic offsets, resource visibility, format support, and device limits.
3. Inspect resource lifetimes and frame scheduling: allocation/reuse policy, pipeline and bind-group churn, staging uploads, synchronization points, resize/device-loss handling, and destruction on scene changes.
4. Identify hot-stage cost: draw/dispatch count, overdraw, visibility and LOD, material switches, buffer traffic, shader divergence, texture sampling, transient allocations, and CPU/GPU wait. Tie each optimization proposal to a measurable frame-time or memory mechanism.
5. Test rendering at boundary dimensions, zero/large values, missing assets, low-end limits, camera extremes, and recovery after resize or device loss. Capture a representative frame or a precise visual assertion; a clean log is not proof of visual correctness.

Completion Gate

Report correctness risks, performance hypotheses, measurements actually taken, resource-lifetime findings, and the visual evidence produced. Keep large-world precision and deterministic visual parameters separate from canonical simulation.

Required Evidence

Record the affected contract, commands and tool versions when material, observed result, unresolved risk, and a regression test or reproducible inspection appropriate to the task.

Trigger

Use Review Rendering when the task requires a bounded engineering review and the affected artifact, acceptance criteria, and authorization boundary are known.

Scope Boundary

This skill reports findings and remediation evidence; it does not claim the complete system is defect-free or approve unrelated components.

Deliverable

A Review Rendering finding set with scope, severity or priority, affected contract, evidence, minimal remediation, and verification status.

Perform Game Security Assessment

Perform Game Security Assessment

Trigger

Use Perform Game Security Assessment when the task requires an explicitly authorized operational assessment and the affected artifact, acceptance criteria, and authorization boundary are known.

Inputs

• Target files, affected runtime path, and explicit acceptance criteria
• Existing architecture, tests, deployment/rollback boundary, and applicable profile
• Authorization and stop conditions when the task has security, production, financial, or external effects

Specialist Procedure

Model hostile clients and economy abuse. Verify server or trusted authority for rewards, inventory, matchmaking, purchases, saved state, replay/rate controls, telemetry privacy, anti-cheat false-positive handling, and safe remediation paths.

1. Map every state transition that carries value — rewards, currency, inventory, ranking, purchases — and where it is decided.
2. Attempt authorized, non-destructive abuse on a test shard: replay, reordering, rate, and client-asserted results.
3. Assess anti-cheat and telemetry for privacy, false-positive cost, and appeal handling as part of the security posture.
4. Deliver server-side validation changes and a retest scenario for each confirmed path.

Required Evidence

• A source-level explanation of the affected contract and invariant
• At least one focused automated or reproducible verification appropriate to the capability
• Explicit treatment of boundary, failure, and unauthorized/invalid paths where applicable
• A measurement rather than intuition for every material performance claim

Scope Boundary

This skill evaluates game trust, economy, and anti-cheat boundaries; it does not justify invasive telemetry, bypassing client protections, or testing players without authorization.

Guardrails

Never expose secrets, claim unrun checks passed, broaden authorized scope, hide a breaking change, or perform destructive/production actions without explicit approval.

Deliverable

A game threat model covering authority, economy, client trust, abuse paths, telemetry/privacy implications, remediation owner, and retest evidence.

Audit Anti Cheat

Audit Anti Cheat

Trigger

Use Audit Anti Cheat when the task requires an adversarial assessment and the affected artifact, acceptance criteria, and authorization boundary are known.

Inputs

• Target files, affected runtime path, and explicit acceptance criteria
• Existing architecture, tests, deployment/rollback boundary, and applicable profile
• Authorization and stop conditions when the task has security, production, financial, or external effects

Specialist Procedure

Define threat model, trusted authority, telemetry minimization, tamper detection limits, server-side validation, appeals, false-positive safeguards, version rollout, and monitoring. Do not collect intrusive data without necessity and consent analysis.

1. Model the cheat classes that matter for this game: client memory edits, injected input, network manipulation, and automation, each with its economic motive.
2. Verify that every competitive outcome is decided by trusted authority, and that detection is a supplement rather than the enforcement mechanism.
3. Assess telemetry against necessity and consent: what is collected, how long it is kept, who can read it, and what a false positive costs a player.
4. Deliver detection changes with rollout, appeal, and false-positive handling, plus the measurement that shows the change worked.

Required Evidence

• A source-level explanation of the affected contract and invariant
• At least one focused automated or reproducible verification appropriate to the capability
• Explicit treatment of boundary, failure, and unauthorized/invalid paths where applicable
• A measurement rather than intuition for every material performance claim

Scope Boundary

This skill evaluates game trust, economy, and anti-cheat boundaries; it does not justify invasive telemetry, bypassing client protections, or testing players without authorization.

Guardrails

Never expose secrets, claim unrun checks passed, broaden authorized scope, hide a breaking change, or perform destructive/production actions without explicit approval.

Deliverable

A Audit Anti Cheat finding set with scope, severity or priority, affected contract, evidence, minimal remediation, and verification status.

Perform Supply Chain Assessment

Perform Supply Chain Assessment

Trigger

Use Perform Supply Chain Assessment when the task requires an explicitly authorized operational assessment and the affected artifact, acceptance criteria, and authorization boundary are known.

Inputs

• Target files, affected runtime path, and explicit acceptance criteria
• Existing architecture, tests, deployment/rollback boundary, and applicable profile
• Authorization and stop conditions when the task has security, production, financial, or external effects

Specialist Procedure

Verify lockfiles, provenance, maintainer/release signals, vulnerable and malicious packages, scripts, transitive reachability, licenses, integrity hashes, CI permissions, and a tested update/removal path. Never silently rewrite dependency locks.

1. Map the path from source to deployed artifact: who can commit, who can release, and what runs in between.
2. Assess build-system permissions, third-party actions, artifact signing, and whether provenance is verified at deploy time.
3. Evaluate dependency integrity: pinned versions, hashes, install scripts, and the maintainer trust behind critical packages.
4. Deliver the smallest set of changes that removes an unreviewed path to production, with verification for each.

Required Evidence

• A source-level explanation of the affected contract and invariant
• At least one focused automated or reproducible verification appropriate to the capability
• Explicit treatment of boundary, failure, and unauthorized/invalid paths where applicable
• A measurement rather than intuition for every material performance claim

Scope Boundary

This skill is limited to its named capability and must not absorb adjacent work that has a separate contract, owner, or verification path.

Guardrails

Never expose secrets, claim unrun checks passed, broaden authorized scope, hide a breaking change, or perform destructive/production actions without explicit approval.

Deliverable

A Perform Supply Chain Assessment result with scope, inputs, outputs, evidence, remaining risks, and the next owner/action.