Define a result you can evaluate
Pick one outcome and explain what success looks like. “Improve the interface” is broad; “make the inventory usable at phone width without covering the jump control” gives you something concrete to inspect.
Provide relevant references and constraints. For a large change, review the plan before beginning dependent work.
Keep decisions with the work
Follow the task's recorded progress and answer only the decisions it actually needs. Check what an approval would permit before giving it.
A workflow should tell you whether work is planned, in progress, awaiting review or complete. Use the controls documented in your software release; an animation or a busy indicator is not proof that work succeeded.
Inspect the actual result
Open the produced files or media and compare them with your brief. For code, run relevant checks; for a game, test the behavior in Roblox Studio and on the devices you intend to support.
A local build does not prove multiplayer behavior, real-device performance or asset quality. Record what was tested and what remains unverified before approving the next step.
Make publishing a separate decision
Review your content rights, configuration and player experience before publishing. Use an experience you control and keep experiments separate from a live game.
BerryBlox does not guarantee a hit, revenue or a particular concurrent player count. Your direction, iteration and testing remain part of making the game.