phaser4-game-workflow-control

Phaser 4 Global Workflow Control

This Skill is the sole state, risk gate, task scope, and evidence control plane for the Phaser project. Ordinary tasks directly follow the current user instruction; domain Skills may iterate within the Work Item scope and return to this control plane upon completion; non-Phaser operations do not enter this process. Ordinary tasks do not require an independent taskAuthorization, authorization record, or F0 authorization validity gate; side-effect-free local A4 may be executed per task, while A4-A6 operations with side effects still retain per-object approval.

Shortest Main Loop

Popup-type transient display layers followindependent work item rulesplanning, implementation, and acceptance;hostSceneId they are bound only to the runtime context and do not indicate ownership. A scene closes the loop only on its own gameplay, visuals, and persistent HUD; an incomplete popup does not block the scene V4, nor does it fall within the implementation scope of the lobby or other host scenes.

Users daily follow simplified-workflow.md 's six-phase project view to understand progress: requirements and scope → global baseline → foundational engineering → per-scene production → global integration verification → release. Single-scene visual tasks advance within per-scene production according to scene definition → decomposition and layout confirmation → formal asset acceptance → formal restoration and runtime acceptance.

Read the current Work Item and record the user's original text, goals, scope, baseline, and acceptance boundaries; when changes occur within the task, update the plan accordingly.
Read the necessary reference according to the current phase, run run or check; when facts are missing, first ascertain them through code, configuration, existing artifacts, and authorized verification. Only when the remaining issues involve substantive user trade-offs that cannot be reasonably inferred should precise questions be raised; work that can proceed independently continues to be executed.
Freeze the implementation package before A3 implementation; implementation units, execution status, visual evidence, and file ownership must be reviewable, and changes to paths, solutions, or resource lists within the task may update this package.
After implementation, record the candidate change audit, first recommend the test level, rationale, coverage, and commands, then automatically execute targeted verification and submit the current candidate evidence; all tasks are judged for acceptance one by one according toactual completion status, and when the current requirements are already satisfied, do not make revising historical contracts a prerequisite for completion.
On failure, select only based on evidence repair、revalidate or the necessary return; do not automatically roll back the shared workspace, expand scope, or repeat already confirmed facts.
After a phase task meets the acceptance conditions, the executing agent automatically commits this task's changes according to the following "Phase Wrap-up and Git Commit," then hands off to the next phase.

Phase Wrap-up and Git Commit

When temporary files for this task need to be cleaned up after phase acceptance, use phaser4-game-artifact-cleanup to verify references and regeneration conditions before executing; when the user requests cleanup of historical records or intermediate artifacts, it is also routed to this Skill. Retain valid evidence and the audit chain; do not automatically delete due to record invalidation, task final state, or Git ignore; the cleanup scope and risk remain managed by this control plane.
After each phase task is completed and passes applicable verification, the executing agent automatically creates a local Git commit on the current branch without asking again; it does not automatically create branches, worktrees, or push to remotes.run、check and the state transition command itself do not execute Git commits.
At task start, record existing workspace and staging-area changes; at wrap-up, verify the actual diff against task file ownership, and stage and commit only the additions, modifications, and deletions involved in this task. Indiscriminate git add . or git add -Ais prohibited; when the same file contains changes from others, isolate by hunk, and if reliable separation is impossible, preserve the scene and report a blocker, without carrying along existing staged content.
Before committing, automatically check untracked files generated by this task and existing ignore rules, and add or update the project .gitignoreas needed, ignoring dependency directories, caches, temporary files, local logs, regenerable build artifacts, and local secret configuration with the minimal scope; include this task's .gitignore modifications in the commit as well. Do not ignore source code, necessary resources, lock files, deliverables, or evidence required for acceptance, and do not use broad rules to conceal unfinished work.
.gitignore does not untrack already tracked files; only remove from the index, while keeping local files, artifacts confirmed to belong to this task and not meant for the repository, without bulk-cleaning other historical files and without force-adding ignored secret configuration.
Before committing, check the selected diff and staged content, and use a concise Chinese commit message; after committing, verify the files included in the commit and the remaining workspace status, and report the commit hash, verification results, and uncommitted items. Skip empty commits when there is no committable diff for this task. If verification fails, the commit fails, or file ownership is unclear, report the reason, do not claim wrap-up is complete, and do not skip Git hooks or automatically roll back.

Progressive reading

For routing or status queries only: read this file and the relevant paragraphs of references/control-model.md .
When state transition or gate judgment is needed: then read references/state-gates.md。
When artifact fields are needed: read the corresponding references/*.schema.jsonby command; do not preload the entire Schema.
When visual tasks are needed: read references/visual-stage.schema.json and the corresponding domain contract; effect images, generative bitmaps, global baselines, and high-fidelity prerequisites are read only when applicable.
When A3 delegation, execution, or evidence is needed: read the corresponding implementation-package、delegation、execution-state、evidence Schema。

Non-bypassable constraints

INTAKE → BASELINE → PROPOSAL → REVIEW → IMPLEMENTING → VALIDATING → PASSED is the normal forward path;run continuously advance the safe control-plane state whose conditions are already satisfied, enter implementation or stop when evidence is missing or a user decision is needed, and never automatically choose RETURN。
The above stop refers only to the control command returning. The execution agent should continue to complete authorized implementation, evidence supplementation, fixes, and applicable verification, then invoke control-plane advancement; pause the corresponding work only when a necessary user decision, explicit approval, or an external blocker that cannot be eliminated on its own is missing, while work without dependencies continues.
A0-A3 are based directly on the current user task; local A4 integration with no external side effects may also be executed per task. Within a task, the plan, path, resource list, and verification scope may be adjusted, and work continues after synchronously updating the plan. A4-A6 operations involving external writes, payment, real devices, destructive or external deletion, or release must create precise pending items and obtain explicit approval object by object. The control plane does not execute these actions.
The actual artifacts of V0→V1→V2→V3→V4, manual selection of the global baseline, scenario V2 decomposition and layout confirmation, high-fidelity prerequisites, and V4 run acceptance must still be verified; handwritten status or a root PASS cannot replace actual files and applicable manual confirmation, and file references no longer require or compare SHA.
AUTO only indicates that there are no additional product trade-offs, and does not replace manual confirmation of global image selection, V2 decomposition, independent layout, or Spine batches. Each gate requests only the confirmation it still lacks; when the coverage facts and bound identity are unchanged, reuse existing valid evidence and do not ask repeatedly.
Art direction and quality followGame Art Experience and Quality Contract. The structured brief for global image selection and the per-candidate manual quality results must pass the real file gate; if any selected candidate fails or is unverified, it cannot be frozen; the machine exit only verifies facts and does not replace the manual results for viewing comfort, theme, and completeness. Without explicit authorization, the agent does not automatically analyze screenshots or video frames.
Programmatic text is incorporated as a hard constraint for implementation and review: English must be implemented simultaneously en, Simplified Chinese zh-CN, Japanese ja, Russian ru, Spanish es, and display verification must be completed using each language's real glyph widths, baselines, font fallback, and container adaptation. On the premise of semantic accuracy and player comprehensibility, copy should remain short and game-like, prioritizing x3、+10, icon + value, and other familiar expressions, and should not write explanatory sentences that can be expressed directly by symbols. Each language independently declares a single-line or line-break strategy; some languages may use single-line and some may use line breaks; truncation is prohibited. When it does not fit, the copy, letter spacing, font size, or container should be adjusted according to that language's strategy while maintaining a readable font size.
check read-only;run read-only verification, derive the route, and may continuously write safe state steps whose conditions are already satisfied, without running business code, tests, services, releases, or external actions.
Only when upstream facts, task scope, actual content, approval target, or implementation plan genuinely change should the affected parts be re-verified; missing or changed summaries do not invalidate old evidence. Adjustments to ordinary paths, plans, and resource lists within a task only update the plan and re-verify the affected parts. Overwriting others' modifications is prohibited.

Image task delivery

Shared by effect image generation and interface implementationIn-game copyRule: internal planning notes and player-visible expressions are kept separate; generation prompts clearly define the scope of visible text, and the formal interface binds the same expression and dynamic data. This applies to global candidates, scene key images, pop-ups, and paths without effect images; existing generation records, domain documents, and manual acceptance are reused, no new approval gate is added, and machine checks are not treated as copy display passing.

Visual tasks followimage-first confirmation method: the agent internally maintains analysis, technical records, and prompts, and directly delivers real images or previews for manual confirmation, without setting up pre-production confirmation gates for routine text proposals, breakdown records, layout decisions, or animation timelines. Rework within the confirmed target scope is directly given as before-and-after comparisons; only decisive requirement ambiguity pauses the affected parts. Actual breakdown, layout, resources, parent frame and video confirmation, and operation authorization follow the original gates, and internal records cannot replace real candidates.

Lenient execution principle

All tasks and stages in the workflow cancel acceptance verification of SHA-1, SHA-256, file hashes, and candidate summaries: these fields are not required to be filled in, recalculated, or compared, and tasks are not blocked, returned, or reopened due to missing, malformed, or changed summaries. Summary checking is left to the processing stage after final manual acceptance; existing summaries serve only as optional tracking. Actual files, task ownership, applicable content constraints, command results, and manual confirmation must still be checked. Summaries for internal caching, plan display, and transactional concurrency protection are not acceptance gates.
Ordinary tasks do not establish independent authorization credentials. The user's current instruction simultaneously provides the execution basis for A0-A3; the Work Item only records the goal, scope, plan, and results, serving as collaboration context and tracking information.
All task and stage acceptance checks verify the current explicit requirements, actual results, and necessary constraints one by one, and judge the impact of each difference; non-mandatory implementation detail adjustments during the process only record the results and re-verify the affected evidence, without retroactively revising the contract or reopening completed work. Adjustments already explicitly raised by the user are directly incorporated into the current requirements; only when the scope, public interfaces, or hard constraints that subsequent dependencies truly rely on are changed should the corresponding contract be updated.
When non-critical metadata is missing, first remind and automatically fill it in; block only when identity, ownership, key artifacts, security boundaries, or the user's substantive trade-offs cannot be confirmed. Ordinary issues default to in-place repair, and when the candidate is unchanged only revalidate。
visual inspection by default checks usability and reasonable relationships, allowing small deviations in position, size, margins, and line wrapping; pixel-level tolerance and full viewport/full state matrices are enabled only when explicitly requested by the user or explicitly specified by the project contract. Out-of-bounds, clipping, critical occlusion, unreadability, and interaction failure must still be fixed.
Tests recommend T0-T3 based on change risk, display the rationale, coverage, and proposed execution commands, then automatically execute the applicable level; do not wait for manual selection, and do not automatically initiate real-device acceptance.

Agent entry point

node <skill-dir>\scripts\workflow-control.mjs run --repo . --work-item <work-item> [--input <file> ...]
node <skill-dir>\scripts\workflow-control.mjs check --repo . --work-item <work-item> [--implementation-package <package>] [--evidence <manifest>] [--input <file> ...]
node <skill-dir>\scripts\workflow-control.mjs status --repo . --work-item <work-item> [--input <file> ...]

The three entry points can repeatedly pass in --input <file> to bind explicit key inputs; by default the text preferentially displays the six-stage/four-step scenario view,--json still outputs a stable status/stage/changed/blocking/next/metadata top-level protocol, and in metadata.workflowView provides the display mapping,metadata.planFingerprint provides a deterministic plan fingerprint of the binding baseline, authorization, status, implementation package, and key input file hashes. Repeating check must be read-only and produce consistent results.

Advanced diagnostics

route derives the route,preflight verifies actions,advance migrates a state that has already satisfied a gate,transition performs explicit state migration,diff-audit records the candidate diff,evidence-check verifies evidence,delegate-check/parallel-check/unit-check manages A3 execution units,prepare-approval/handoff/approve serves only precise A4-A6 operations with side effects,lint performs repository-level static checks. Advanced commands do not change the above scope or hard gate semantics.

Domain collaboration

$phaser4-game-orchestrator is responsible for domain orchestration; production, architecture, gameplay, visual, resource, audio, numerical, QA, performance, and release Skills may only submit proposals, review conclusions, implementation packages, or evidence, and return to this control plane to complete state migration.

For detailed status, gates, Schema, visual contract, and rework rules, see control-model.md、state-gates.md、schemas.md、visual-stage.schema.json and return-disposition.mjs。