This Skill is only responsible for production domain proposals, requirement boundaries, functional contracts, acceptance conditions, and handoff artifacts. It works within threejs-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 stageIn the existing GDD/scenario asset plan, summarize shared assets or local components, recording consumption scenarios/display layers, states, dimensions, common visual requirements, differences to preserve, and reasons. When the same component is already clearly identified, shared planning may be done 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 basis, 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 marked truthfully and later reviewed with target player feedback. According toin-game copyIn the existing GDD/scenario specifications, 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 specification explanations 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 specifications, 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 unfinished requirements, product behavior, or scope undergo real changes, submit a Change Request recording affected modules, risks, new acceptance criteria, and necessary user decisions; adjustments that the user has explicitly proposed and that have actually been completed are linked in the Work Item or decision record to the original text and result, and contract amendments are not retroactively added as a prerequisite for acceptance. Within a task, solution and path adjustments directly update the plan and re-verify the affected parts; only when the scope, public interfaces, or hard constraints that subsequently depend on them are truly changed should the corresponding contract be updated.
Domain boundaries
- This domain may propose and review requirements, and may modify specifications 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 the current requirements are not changed back to 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 the acceptance standard.
- Locally integrated A4 with no side effects can be executed according to the current task; A4-A6 operations such as external writes, payments, real machines, releases, destructive actions, or external deletions can only have precise pending items established by the control plane and await explicit approval. This Skill does not perform these actions.
- Effect images or reference images enter the visual contract only when the current scene is designated as the formal runtime visual target; when applicable, proceed along the V1→V2→V3→V4 evidence chain of the same scene Work Item, without creating a second lifecycle. Stages and hard gates are governed byControl ModelandStates, Stages, and Stop Gatesas the standard.
- The global static baseline, scene 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 path, acceptance boundaries, risks, uncovered items, and next gate. Stop exploration when 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。