Use reproducible steps and real evidence to explain whether a feature holds; do not infer runtime passes from static code. Before starting, read the acceptance criteria, target platform, architecture/Remote contracts, performance budgets, andplugin routing。
For the visible experience, follow theresponsive UI contractto cover the real target matrix, and follow thevisual workflowto record the five manual quality conclusions and four types of dynamic scenarios. Machines only verify fields, technical parameters, and real runtime evidence; screenshots are checked by the user, and technical PASS must not be automatically written as visual PASS。
Follow thecoverage contractto bind approved test cases line by line with actual Client measurements; reusing one Play for other viewports or scenarios is prohibited. For overall project delivery, follow theproject dependency contractto run check-project; for multiple Places, only check relational contracts and real runtime evidence after explicit enablement; single-client and single-Place evidence cannot replace cross-Place conclusions.
Responsibilities and Inputs
- Check the actual Studio state, target Place, existing tests, and code; retain versions, test cases, results, and original error text.
- When acceptance scope, budget, or risk acceptance requires real user trade-offs, hand off to theinterrogation skillfor recording; ordinary tests are executed automatically according to the already recommended level, and the addition of the interrogation skill does not require manual reselection of tests.
- Only when the user requests unit tests, test coverage, running tests, or debugging test failures, load rbx-unit-test; performance analysis routes to rbx-perf-profiling.
- Use rbx-debug when breakpoints and suspended-thread diagnostics are needed; in paused callbacks, do not modify the DataModel or call yield.
- SceneAnalysis requires actual runtime state, feature flags, and allowed perspectives; LibMP analyzes at most 256 frames and releases objects as required by the tool.
- The device emulation API is an asynchronous task; select the actual ID from the device list returned by the tool, and wait for the task's terminal state; set the device before entering Play, because in the PlayServer state the setter will fail.
- When Studio currently only has a single-client Play operation entry point, it does not constitute multi-client acceptance; when there is no dedicated Server & Clients MCP, mark it as not run truthfully.
Execution Steps
- First break acceptance down into normal paths, invalid input, permissions, rate limits, repeated calls, player exit/respawn, Streaming absence, resource failure, and regression paths.
- For each test case, record the initial state, executed operations, expected, actual, evidence, version, and severity; pass conditions come from the current acceptance criteria, and do not set your own thresholds.
- Use start_stop_play only in authorized Studio workflows; after running, read get_console_output and record errors and warnings.
- Keep single-client results separate from multiplayer contention verification; when a multi-client environment is lacking, static review may report risks but must not claim that concurrency tests passed.
- For performance analysis, first record the real scenario, player/instance counts, device or emulation settings, sampling window, and tool version, then collect comparable metrics.
- Distinguish script hotspots, instance counts, resource loading, network requests, and rendering bottlenecks; provide reproducible trigger conditions and evidence.
- When using device emulation, record the real device ID, screen orientation, input path, and final state of asynchronous tasks; mark incomplete tasks as NOT_RUN.
- Order defects by impact and reproduction stability, return them to the respective owner for fixing; only re-verify affected test cases and necessary regressions.
Evidence and Stopping Conditions
- Output the test case matrix, defect list, console results, performance metrics, test environment, uncovered items, and re-verification status.
- screen_capture is only used for the Edit state; do not use it to fabricate evidence of running screens. Do not automatically analyze screenshots without explicit request.
- Visual display is manually checked and confirmed by the user via screenshots; no screenshot alone can prove that input, security, multiplayer, or performance passed.
- When requirements for data writes, online services, device startup, or external publishing arise, stop at a reviewable plan first and obtain the corresponding authorization.
Server & Clients, target devices, device performance, or real-running visual test cases that have not been run must be marked NOT_RUN and must not be claimed as passed.
- Remote boundaries are established according to architecture and gameplay development ; receipts, persistence, and purchase regressions are covered according to the LiveOps contract.
Performance and Stability Report
- Runtime sampling records server/client side, scene, player count, duration, sampling method, and resource version.
- Record server script time, client frame rate, memory, network messages, instance count, and asset loading as separate items.
- When comparing data before and after, fix the run procedure and test configuration; if the environment differs, clearly mark it as not directly comparable.
- Before analyzing script hotspots, confirm that sampling covers the target events; a brief anomaly cannot be directly inferred as a persistent regression.
- Roblox device emulation is simulated coverage evidence and cannot replace real-device runs, input experience, or actual network quality.
- Real player privacy or online telemetry data is used only when authorized, with minimal scope, and with a clear purpose.
- Report conclusions reference actual logs/task results; screenshots are only manually confirmed by the user for visual presentation.