This Skill is only responsible for production domain proposals, requirement boundaries, functional contracts, acceptance conditions, and handoff artifacts. It works within phaser4-game-workflow-control 's Work Item, current user task, and A-level scope, and returns review conclusions to the control plane; it does not replace human decision-making, and does not own state or approval ledgers.
Shortest process
- Read the Work Item, current task description, project configuration, GDD, and applicable reference evidence; organize the minimum facts using the F0-F4 quality gates.
- Break the current task scope into gameplay/support scenarios, player behavior, state transitions, dependencies, formal asset boundaries, exception recovery, and observable acceptance results; behaviors that cannot be determined from static evidence are explicitly marked as to be defined. When determining features and splitting scenarios, followShared planning for the feature and scenario phasesIn the existing GDD/scenario asset plan, summarize shared assets or local components, recording consuming scenarios/display layers, states, dimensions, common visual requirements, differences to be preserved, and rationale. When the same component is already clearly identified, sharing may be planned in advance; when only the function is the same, the visuals are similar, or the appearance is undetermined, keep it as a candidate and leave it to subsequent visual breakdown and formal artifact review.
- In the GDD, maintain the core loop, full scenario list, functional contracts, acceptance conditions, and the traceability of "requirements → features → modules → scenarios → assets → test evidence"; write channel priorities and capability switches into the project configuration. Tasks with visual design scope should also followGame art experience and quality contractHand off the project theme, audience and rationale, experience goals, viewing context, core focal areas, and three-layer feedback intent, and write them into a structured art brief. MDA experience goals are used to connect gameplay and art, and specific goals are not replaced by "high-end, stunning"; unverified player preferences are truthfully marked and later reviewed with target player feedback. FollowIn-game copyIn the existing GDD/scenario specs, separate internal rules from player-visible expression, and hand off icons/images, numeric formats and sources, allowed short labels (which may be empty), and display conditions; the same expression is reused by the art brief, mockups, and implementation, and spec interpretations are not handed directly to the interface. Only when the task explicitly involves juiciness/dynamic feedback, or when core events lack clear feedback semantics in the existing specs, refer as needed toJuiciness design guide; production determines expression intent and key events in the existing GDD/functional contract, and does not require a separate document.
- When incomplete requirements, product behavior, or scope genuinely change, submit a Change Request, recording affected modules, risks, new acceptance criteria, and necessary user decisions; for adjustments the user has already explicitly proposed and that have actually been completed, associate the original text and results in the Work Item or decision record, and do not retroactively add contract amendments as a prerequisite for acceptance. Within a task, plan and path adjustments directly update the plan and re-verify the affected parts; update the corresponding contract only when scope, public interfaces, or hard constraints that genuinely change subsequent dependencies are affected.
Domain boundaries
- This domain can propose and review requirements, and can modify specs within the current task path; the A3 implementation package is frozen by the control plane before being handed to the implementer.
- All tasks are accepted one by one according toactual completion statusacceptance; tasks that meet current requirements are not retroactively changed in the GDD or contract due to mid-course implementation adjustments. Requirements that are not met should be fixed in the actual delivery, and the contract cannot be revised to lower acceptance standards.
- Side-effect-free local A4 integration can be executed according to the current task; A4-A6 operations such as external writes, payments, real devices, releases, destructive actions, or external deletions can only have precise pending items established by the control plane and wait for explicit approval. This Skill does not execute these actions.
- Effect images or reference images enter the visual contract only when the current scenario is designated as the formal runtime visual target; when applicable, proceed according to the V1→V2→V3→V4 evidence chain of the same scenario Work Item, and do not create a second lifecycle. Stages and hard gates are based onControl ModelandStatus, Stages, and Stop Gates.
- The global static baseline, scenario direction, and high-fidelity evidence are uniformly validated by the control plane; this domain only provides experience intent, functional facts, and scope, and does not replace machine evidence with text or root summaries.
Handoff and Convergence
Production output retains only the current Work Item's status package, GDD/contract paths, acceptance boundaries, risks, uncovered items, and the next gate. Stop exploration when the facts are sufficient and there are no substantive trade-offs; handle issues according to repair、revalidate or the necessary minimum scope return , and return to the control plane to run check/run。