القائمة
Design deterministic tests for GML gameplay, scripts, resources, and runtime behavior. Use when adding features, fixing regressions, or validating an Auto-Game build.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Create and modify GameMaker resources through structured project tooling. Use when working with objects, events, rooms, scripts, instances, project metadata, or resource relationships.
Use this skill to remove compatibility shims, legacy behavior wrappers, and import/export pass-through files by migrating call sites to direct ownership APIs.
Organize GameMaker resources, manage layout and naming, structure project notes, and establish reusable architectural systems. Use when organizing resources, naming systems, or structuring GameMaker projects.
Use Playwright to inspect, navigate, and play a running browser-based GameMaker game. Use when the user wants the agent to verify gameplay, menus, input, screenshots, browser behavior, or the exported HTML5 game loop. This skill is for operating the game through the browser like a player, not for editing code.
Understand and work with GameMaker Language (GML), including its syntax differences from JavaScript, GML-specific language constructs, data accessors, keywords, constants, and formatting conventions.
Apply adversarial verification during any meaningful code change before the approach hardens. Use for medium or larger changes where regressions, hidden coupling, ownership mistakes, or invalid assumptions are plausible. Skip only for trivial mechanical edits.
| name | gmloop-gml-tests |
| description | Design deterministic tests for GML gameplay, scripts, resources, and runtime behavior. Use when adding features, fixing regressions, or validating an Auto-Game build. |
Choose the lowest test level that can prove the behavior without depending on unrelated engine state.
Do not replace a fast unit test with a runtime test when engine behavior is irrelevant. Do not claim runtime behavior is verified from parsing or static validation alone.
Control random seeds, game clocks, input sequences, initial state, and fixture data. Mock or bypass dynamic time steps (like delta-time) and random number generators (randomize()) to ensure identical test execution. Keep tests independent of execution order and prior runs. Clean up created instances, files, rooms, and persistent state after every run.
Test observable behavior rather than private implementation details or incidental log wording. Assert stable identifiers, state variables, returned outputs, resource relationships, and structured diagnostics.
For a feature, cover the primary success path and the most important boundary or failure path. For a regression, first add a test that fails for the reported behavior, then fix the source and keep the test.
Relevant cases commonly include:
Run the narrow tests during development, then the relevant project validation and build checks. Report exact commands, pass/fail counts, fixture or runtime used, and behavior that remains manually verified. Never hide a failure by weakening an assertion or changing a golden fixture unrelated to the requested behavior.
