← ClaudeAtlas

determinism-auditlisted

Audits nondeterministic game behavior and flaky execution. Use when the same initial state and inputs produce different outcomes, a test fails intermittently or only under load, behavior differs by frame rate or machine, a replay diverges, or lockstep peers desynchronize. Establishes the required determinism boundary, reproduces and measures variance, isolates randomness, timing, async or thread ordering, state leakage, unordered iteration, and numeric drift, then reports verified causes and implements and stress-tests fixes only when requested.
NEXPACE-Limited/msu-skills · ★ 7 · AI & Automation · score 65
Install: claude install-skill NEXPACE-Limited/msu-skills
# Determinism Audit Define what must repeat, expose the first divergence, and distinguish a verified cause from a lead. ## 1. Inspect the project and define the contract Identify the engine or runtime, build and test commands, simulation loop, RNG ownership, concurrency model, persistence, networking, and replay format. Determine whether the request is an audit or includes authorization to change code. Define the boundary before testing: - the build and version; - initial state and seed; - ordered inputs and simulation ticks; - same-machine, same-platform, or cross-platform requirement; - whether replay, lockstep, or cross-version compatibility is required. For replay, lockstep, or cross-platform work, read [determinism-contracts.md](references/determinism-contracts.md). ## 2. Characterize the variance Replay a known failing seed, input trace, test order, or schedule first. Otherwise repeat the smallest failing case enough to expose its trigger conditions and estimate the observed failure rate. Choose the sample from the observed rarity and risk rather than using a universal minimum. Record machine and platform, frame or tick rate, load, test order, external responses, and every hidden input the contract does not hold fixed. If the failure remains unreproduced, add logging or state snapshots and report the cause as unverified. Authorized hardening of an independently confirmed unsafe construct is still possible, but it is not a verified fix for the reported failure.