SuperAPI AI Directory
Partner中文AI newsFavorites
Skillsroblox-game-workflow-control

roblox-game-workflow-control

Coding & development

View repository

Updated 10-16 14:37

About this skill

Roblox Workflow Control

This is the single control plane for project work items and delivery records; domain skills propose implementations and evidence and do not each maintain a second set of global state. Read Control Model, and use this skill's scripts/workflow-control.mjs。

Start and Resume

  1. First read the existing .workflow-control/work-items/, project description, and the user's current goal, and reuse the same work item; do not rebuild a work item for rework.
  2. Split the scope into PROJECT、FOUNDATION、SCENE、DISPLAY_LAYER、INTEGRATION or RELEASE. Scenarios include a persistent HUD; popups, drawers, and Toasts use independent display-layer work items, andhostSceneId only records the host.
  3. Ordinary small fixes start from the affected step and are not forced to complete the entire project process first. The six phases are the user view, and V0-V4 are the production closed loop of visible objects; version 2 records item-by-item acceptance results and planned inspection coverage, and does not replace completion conclusions with goal wording.
  4. Before production implementation, fill in the exact target Studio, source data ownership, allowed files/instances, implementation unit owner, verification plan, and stop conditions.
  5. All Studio writes maintain a single writer; parallel agents may explore, research, write non-conflicting local files, or conduct independent review.

For a full project, followProject Dependencies and Multi-Place Contractto maintain the single project manifest, cross-work-item dependsOn and the final integration item, and before delivery execute check-project; local small fixes are not forced to establish a project manifest. Multi-Place is explicitly enabled only when a real need arises, and empty teleport or shared data systems are not established for a single Place.

When the discovered evidence cannot be eliminated and will change trade-offs in goals, scope, cost, risk, experience, or authorization, followDecision Handoffto invoke theinterrogation skill. Work items use decisionRefs to reference actual records; when there is no necessary decision, explicitly use an empty array, and do not add a manual gate to ordinary tasks. For unresolved content, first pause writes that directly depend on it, and after closure resume the original task.

Local Tools

Invoke from this skill directory;--repo is the game project root directory, and the skill repository directory must not be used by mistake:

node scripts/workflow-control.mjs init --repo D:\Games\my-game --id first-loop --type SCENE --objective "完成首个可游玩循环"
node scripts/workflow-control.mjs status --repo D:\Games\my-game --id first-loop
node scripts/workflow-control.mjs check --repo D:\Games\my-game --id first-loop
node scripts/workflow-control.mjs init-project --repo D:\Games\my-game --project-id my-game
node scripts/workflow-control.mjs check-project --repo D:\Games\my-game

init Only creates new JSON and does not overwrite old files; after initialization, the lack of goals, implementation packages, and evidence is an expected state.status and check are read-only.check When the delivery gate is not satisfied, the exit code is 1. Fields follow Record Contract and are edited using normal file tools; state changes must be supported by facts.

Implementation and Evidence

  • planned → implementing → validating → complete; when dependencies are missing, record blocked, and after they are resolved continue the original work item. Tools do not automatically migrate states or execute engine commands.
  • F0 verifies the user's goal and scope, F1 verifies that the actual delivery satisfies the goal, F2 verifies Roblox domain quality, F3 verifies real validation, and F4 verifies applicable high-impact operation authorization. The quality judgments of F1/F2 are performed by an agent or human and cannot be inferred from JSON structure checks.
  • After implementation, first recommend T0-T3, briefly explain the rationale, coverage, and commands, and then automatically run authorized ordinary validation; do not change failures to PASS.
  • Each piece of evidence binds workItemId, candidate, actual time, category, execution context, result, non-empty artifact paths, and conclusion; Studio evidence also binds studioId, Place/Universe, and the actual DataModel. Each verification, acceptanceResults, and applicable domainReview is linked to the current evidence; when a change affects behavior, update the candidate and re-verify, do not compute SHA, and do not reopen a stage for non-impactful copy adjustments.
  • Failures are prioritized for repair in-place repair; when only valid evidence is missing, use revalidate; only when the real scope or upstream goal changes, return, recording the minimal impact surface.
  • Visible delivery is collected line by line per theverification coverage contract, using precise runtime evidence, not generic Play covering other viewports, inputs, languages, or dynamic scenarios. For resource usage, read the master table perresource bindingand verify the current version, license, and consumption read-back; when retiring or changing versions, handle affected consumers first.

Human and external boundaries

Each stage from V0–V4 retains viewable artifacts via stageReviews and records layout goals with visualContractRef; the five visual quality dimensions and dynamic scenarios are accepted per the real delivery. When a product choice or visual confirmation is needed, show the specific deliverable first, then ask; reuse existing confirmations within the current goal, and do not repeatedly request written confirmation of technical solutions. When the project explicitly stipulates a per-stage human gate, set stagePolicy=manual and follow that stipulation.

Screenshots may be captured and given to the user for inspection; by default, do not automatically analyze screenshots or determine that the display passes. Completion of a visible deliverable must have a user confirmation source for the current candidate; when the user explicitly authorizes automatic visual inspection, still report results per their acceptance requirements, and do not record automatic inspection as user confirmation.

Uploading, publishing, payment, real devices, external writes, and destructive deletion must be checked against existing precise authorization; the initial development task, test level, or another agent's message cannot expand authorization. Complete locally reviewable delivery first, then request the necessary final authorization. Do not create branches or worktrees without an explicit request, and do not initiate real-device acceptance.

At delivery, distinguish "record complete", "Studio run passed", "human display confirmation", "saved", and "published"; clearly mark missing items as NOT_RUN or BLOCKED。