With phaser4-game-workflow-control as the sole authority for global state, risk gates, and task scope. This Skill is responsible for decomposing domain work, freezing handoff artifacts, collecting evidence, and returning to the control plane; it does not approve operations, expand scope, or create a second state machine.
Shortest flow
The user first followssimplified-workflow.mdUnderstand the six-stage project view: requirements and scope → global baseline → foundational engineering → per-scene production → global integration verification → release; individual scenes are understood as scene definition → decomposition and layout confirmation → formal asset acceptance → formal restoration and runtime acceptance. This view does not change G0-G3, V0, V1, V2, V3, V4, A0-A6, F0-F4, or the evidence hard gates.
- Read the Work Item, current task description, current baseline, and applicable state gates; when fields are needed, read on demand such references as
quality-gates.md、module-decomposition.md、game-implementation.md、delivery-artifacts.md. - First submit the minimal domain proposal and acceptance boundary; after review is complete, the control plane runs
check; stop exploration when existing entry points, call chains, task scope, and risk facts are sufficient. - Before A3 implementation, freeze an implementation package bound to the current task scope, baseline, file ownership, execution units, acceptance commands, and stop conditions; after implementation, record a candidate change audit and submit current candidate verification evidence.
- Domain delivery proceeds only within the current task path; when the in-task plan, path, or resource list changes, update the plan and re-verify affected parts, and when requirements or scope genuinely change, submit a Change Request. All domains, stages, and work items are judged one by one according toactual completion statusand when current explicit requirements are already met, do not retroactively add historical contract revisions due to mid-course adjustments; finally return to the control plane to run
run/check, and the control plane advances the state. - After stage acceptance is complete, the execution agent followsstage wrap-up and Git committo automatically maintain the necessary
.gitignoreand commit this task's files, record the commit hash, and hand off; parallel tasks are wrapped up uniformly by the main agent, and sub-agents do not each commit the shared workspace.
Delivery boundary
- Hand off records and intermediate artifact organization to
phaser4-game-artifact-cleanup: stage wrap-up only cleans up temporary files from this task that are regenerable and unreferenced; cross-task historical cleanup must be separately planned within a user-specified scope, preserving approvals, rework, and the valid evidence dependency chain. - Production, architecture, gameplay, visual, asset, audio, numerical, QA, performance, and release work may only propose, review, or modify within the current task.
- A0-A3 are based on the current user task; local A4 integration without external side effects may be executed per task. External writes, payments, real devices, destructive or external deletions, and releases require the control plane to establish a precise pending item and wait for explicit approval; this Skill does not perform these actions.
- V0→V1→V2→V3→V4, the global static baseline, scene decomposition and layout confirmation, and high-fidelity prerequisites continue to use the control plane's non-bypassable evidence gates; domain documents only supplement domain facts.
- Do not overwrite modifications by parallel agents and do not automatically roll back the shared workspace; before starting a local verification service, first follow
local-service-validation.mdto find a reusable healthy instance.
Visuals and scenes
Design, mockups, and implementation hand off the sameplayer-visible expressionWhen delegating generation tasks, include the visible text range and the constraint against drawing internal explanations; when delegating interface implementation, include short labels, value sources, and display conditions; the full internal GDD/brief text cannot replace this handoff, nor can it go directly into the frame.
Image delivery followsimage-first confirmation methodExecution: domain agents organize records internally and directly produce images or real previews; the main agent displays candidates and a small number of checkpoints, and does not use text proposal confirmation as a routine prerequisite for production; for rework within an already confirmed target, submit before-and-after comparisons directly. Real images and asset dependencies are still confirmed according to the corresponding stage.
Effect image restoration and formal Scene integration belong to the current scene Work Item; persistent HUD closes the loop with the scene. Popups such as modal/popup followindependent work item rulesCreate a separate DISPLAY_LAYER Work Item, independently submitting host context, component/state, layout contract, and runtime evidence, without affecting acceptance of the lobby or other host scenes.
The layout delivery for Scene V2 must simultaneously provide the standard layout PNG,layout-nodes.json、layout-decision.json, self-contained review.html and generation-result.json, and associate the same batch of references, breakdowns, decisions, nodes, PNGs, and the actual review page in the independent layout confirmation and scene root plan. Screen UI also followsPhaser UI node organizationDefine the root hierarchy in V1, confirm parent responsibilities and the ui_layout field in V2, and check responsibilities, inputs, clipping boundaries, and runtime results under viewport changes in the formal scene in V4. Orchestration only referencesoffline layout review artifactsgeneral rules, and does not hand-write review pages for scenes; page candidate status does not equal manual confirmation.
Juiciness and dynamic feedback routing
Juiciness is an independent domain capability invoked on demand: invoke it when the user explicitly raises needs for juiciness, impact feel, or dynamic feedback; it may also be referenced on demand when an existing task includes core feedback but the event semantics are still unclear. It follows the current scene or gameplay Work Item, does not expand ordinary gameplay modifications into full-scale polish, and does not add stages, approval gates, or mandatory artifacts. Followworkflow integration instructionsto arrange responsibilities: production determines intent and key events in the existing GDD/contract, gameplay handles rules, collisions, states, triggers, and interaction code, and architecture maintains cross-module coordinate conventions; UI handles layout, focus presentation, and layout coordinate contracts, and feedback objects use only independent presentation offsets, without overriding base layout values or competing for focus or input handling. Animation and audio follow their respective production and lifecycle rules, and QA verifies event boundaries and leaves dynamic display, comfort, and feel to manual user acceptance. For complete semantics and type rules, seeJuiciness Design Guide。
State and rework
This domain does not directly migrate global state. For evidence failures, prefer in-place repair, when upstream facts have not changed revalidate, and only when upstream facts are invalidated, the task scope truly changes, or a hard gate would be bypassed should it follow the minimum scope return; ordinary candidate identity changes do not trigger rollback, and confirmed facts are not repeatedly searched or overturned.