Imported from ouguowen/cocos-studio-ouguowen (SKILL.md). Install upstream with npx skills add ouguowen/cocos-studio-ouguowen. Copyright stays with the author.

Cocos Studio Ouguowen

Name: cocos-studio-ouguowen
Author: ouguowen

Use this skill as the lightweight operating entry for AI Game Studio and Cocos Creator 3.8.8 production work.

The entry file is intentionally small. It keeps the Skill定位, Task Router entry, core safety constraints, and routing rules in memory, then loads detailed production, validation, workflow, Agent, and architecture context only when the request directly needs it.

Skill Positioning

This skill is for:

Cocos Creator 3.8.8 game projects.
AI Game Studio planning, scoping, implementation control, validation, release review, and safe Skill maintenance.
Multi-game-type Cocos workflows, not a single fixed game template.
Provider-neutral Cocos automation guidance when the user explicitly authorizes real project work.

This skill is not for:

Cocos2d-x C++ engine guidance.
Multi-engine game development.
Importing the full Cocos manual.
Treating one MCP, image tool, or automation provider as a core dependency.
Turning Skill maintenance into real game implementation.

Core Startup Context

Always start with Knowledge Index Query Mode.

Default machine routing entry:

Human safety baseline:

Use the index files first to identify response mode, capability family, trigger, loading tier, engine domain, and required module paths. Load detailed Markdown only after the index points to the needed module.

core/module-index.md remains the human-readable routing reference and is loaded only when the task needs detailed module selection or audit explanation.

Do not load the full Skill repository by default. Do not load all gates, workflows, templates, agents, semantic models, architecture files, or proof documents during normal Fast Build Mode.

Knowledge Index routing is metadata-only. It must not create a Runtime Loader, Agent Runtime, Controller, Scheduler, Execution System, or external-tool bridge.

Response Mode Router is metadata-only. It selects exactly one primary answer mode before Task Router or detailed context loading:

DIRECT_ANSWER: ordinary questions and simple technical consultation.
ANALYSIS_REVIEW: analysis, comparison, risk review, and read-only inspection.
DESIGN_PROPOSAL: high-impact Skill, Runtime, Agent, Gate, Context, or repository-structure evolution.
DEVELOPMENT_EXECUTION: explicit create, modify, implement, fix, delete, or direct execution task.
VALIDATION_AUDIT: review, audit, QA, validation, regression, simulator, device, or platform acceptance task.
RELEASE_OPERATION: commit, push, tag, release, merge, publish, or platform submission task.

Ordinary questions default to DIRECT_ANSWER: conclusion first, necessary explanation only, no task status card, no progress, no Agent roster, no Proposal, and no fake execution result.

Execution Protocol Layer is trigger-only. When Response Mode Router selects DEVELOPMENT_EXECUTION, load studio-execution-protocol metadata and route through:

Response Router
-> Execution Protocol
-> Task Graph
-> Validation Layer

The Execution Protocol normalizes request context, task handoff metadata, validation hooks, and result shape. It does not create a new Runtime Controller, Agent Runtime, Scheduler, Engine Adapter, or direct Cocos execution path.

Studio Organization Layer is trigger-only. It maps one responsible role, optional domain capability, authority boundary, escalation path, and compact status display metadata. It does not create AI Employees, Agent Runtime, Agent Controller, Scheduler behavior, Task Graph behavior, or Cocos MCP access.

Fast Execution Guard is trigger-only. Before any tool-driven repository scan, recursive directory inspection, project-size analysis, or DEVELOPMENT_EXECUTION operation, create a Guard Decision through execution/fast-execution-guard.js.

Guard rules:

Do not start recursive scans before a Guard Decision exists.
For 20MB/project-size questions, classify the first pass as READ_ONLY_ANALYSIS + FAST_EXECUTION + ANALYSIS_GUARD.
If the target artifact is unclear, ask one question instead of scanning build, temp, library, and assets together.
Respect time, command, context, and scan budgets as hard stop conditions.
When any budget is exhausted, stop immediately and return BUDGET_EXCEEDED or PARTIAL_ANALYSIS.
Do not rerun the same command or recursive scan with the same path and parameters.
Read SKILL.md at most once per task unless its hash changed.
After context compaction, restore from Execution Summary instead of restarting the scan.
Never exceed budget just to produce a more complete answer.

Context Management Layer is metadata-only. Use core/index/context-loading-policy.json to create a compact Context Plan, enforce minimal module loading, isolate history documents, reuse cache summaries, and stop context expansion when budget or evidence is sufficient.

Context Management must not call tools, control Cocos MCP, schedule tasks, create Agent Runtime, create Context Runtime, modify projects, or bypass Fast Execution Guard. It only provides context loading policy, module load sets, exclusion sets, cache metadata, usage summaries, compression policy, and stop decisions.

Context Runtime is trigger-only. Load context-runtime/context-runtime.js only when a task explicitly needs runtime context planning, Context Package creation, cache restore, or context budget enforcement beyond static policy. It consumes v0.11 Context Management policy and existing Knowledge Index metadata, then passes compact context metadata to the existing Execution Protocol. It must not call shell commands, Cocos MCP, Scheduler, Agent Runtime, Engine Adapter, Provider, Git release operations, or real project writes.

Use:

FAST_CONTEXT for normal implementation, small fixes, and Skill maintenance inside the approved repository scope.
GATE_CONTEXT for pre-write approval, QA, release, stage transition, runtime proof, and safety gates.
AUDIT_CONTEXT for repository audits, validation-script review, release governance, and Skill self-tests.

Shared Context And Router Entry

AI Game Studio execution starts with Knowledge Index routing, then a shared Blueprint context, then routes the task and activates only relevant Agents.

Codex must treat this Skill as the AI Game Studio execution entry for Cocos production tasks.

All Cocos development tasks must enter Runtime Controller before execution planning, adapter mapping, mock execution, or any future real tool call.

Cocos development tasks include scene, prefab, node, component, asset, browser preview, runtime proof, .scene, .prefab, .anim, .meta, or Cocos Creator project work.

The v0.3.0 Agent Orchestration Layer lives in task-router/README.md and task-router/agent-orchestration-router.js.

Orchestration path:

Codex Skill Entry
-> Task Router
-> Runtime Controller
-> Runtime State
-> Studio Response Protocol
-> Presentation

The orchestration layer must not call Cocos MCP, create a new execution layer, change Runtime Controller core code, or change Task Graph execution logic.

Shared Blueprint context lives in blueprint/blueprint-manager.js. Knowledge Index routing lives in core/index/studio-index.json, core/index/module-registry.json, and core/index/trigger-map.json. Incremental dependency impact lives in dependency-graph/dependency-graph.js. Routing policy lives in config/task-routing.json. Runtime routing code lives in task-router/task-router.js. Adaptive execution routing chooses Fast Path or Full Pipeline from task complexity and dependency impact. Execution Memory records route decisions in execution-memory/execution-memory.js. Execution Cache accelerates repeated routes in execution-cache/execution-cache.js. Execution Feedback Loop improves future routing in execution-feedback/feedback-engine.js. Fast Lane validation lives in task-router/fast-execution-path.js. Dynamic Agent activation lives in agent-router/agent-router.js.

Default flow:

Request
-> Knowledge Index
-> Blueprint Manager
-> Dependency Graph impact
-> Task Router
-> Adaptive Execution Router
-> Execution Cache
-> Execution Memory
-> Execution Feedback Loop
-> Agent Router
-> Selected Agent Context
-> Executor or existing Studio Pipeline

Levels:

L0: parameter, UI, copy, or configuration small change.
L1: normal feature, interaction, component, page, or localized bug fix.
L2: system-level, architectural, cross-module, runtime, framework, or pipeline work.
L3: complete production, release, end-to-end, full game, or unknown broad request.

Execution paths:

L0 and L1 may use Fast Lane when policy allows.
Fast Lane may run only blueprint-manager, task-router, agent-router, capability-loader, agent-executor, and validation-agent.
Fast Lane must bypass Planner, Task Graph, Scheduler, and Loop.
L2, L3, unknown requests, release requests, production requests, and force-full signals must enter the existing Studio Pipeline.
execution_enabled remains false; default execution mode remains mock.

Blueprint context is shared, versioned, and sectioned by Agent:

artist: visual, assets, ui
cocos-programmer: systems, code, components
game-designer: design, gameplay
qa: validation, test

Dependency impact maps Blueprint changes to affected Agents so small updates do not reactivate unrelated roles.

Execution results are evaluated and used to improve future routing decisions.

Target Platform Validation is trigger-only. Load protocols/platform-validation/acceptance-gates.md, protocols/platform-validation/evidence-policy.md, validation-agent/platform-validation.js, and production/platform-profiles/douyin-mini-game.json only when a task touches Canvas, Camera, SafeArea, layout, orientation, touch, drag, coordinate conversion, platform build settings, platform APIs, or the user reports that Cocos Preview works but a target platform fails.

Platform Smoke Gate checks target-platform evidence for platform-sensitive changes. Platform Release Gate checks target-platform evidence for milestone, release candidate, formal game version tag, platform submission, or explicit full platform acceptance work. Cocos browser Preview is useful proof, but it is not target-platform PASS.

Operation Routing

Choose the operation mode before loading detailed rules:

Fast Build Mode: normal implementation, small feature, bug fix, approved dev story, or focused Skill maintenance.
Safe Gate Mode: pre-write approval, QA, release review, generated meta review, runtime proof, or stage transition.
Audit Mode: Skill validation, repository audit, release governance, security review, or validation-script review.

Normal game development must not default to Audit Mode. Safety gates remain mandatory, but they should appear at stage boundaries or real stop conditions.

Communication Rules

Default response mode is selected by presentation/response-mode-schema.json.

DIRECT_ANSWER is the default for ordinary questions. studio_mode remains the default for production execution, validation audit, release, and other status-bearing Studio work.

AI is not a chat assistant during production work. AI acts as a game production team and reports through the Presentation Layer.

Default communication is result-first and process-hidden:

show project status, task status, current stage, completed results, errors, blockers, and validation state
hide internal execution thinking, tool-call details, file-operation narration, and repeated preparation steps
do not narrate ordinary preparation such as "I am creating a file", "I will call a tool", or "I am analyzing a file"
ask the user only when an error, blocker, scope ambiguity, forbidden file, missing proof channel, or required user decision appears

Presentation rules live in presentation/README.md, presentation/studio-mode.md, presentation/studio-status-template.md, and presentation/output-policy.md. Response mode routing lives in presentation/response-mode-schema.json.

Presentation is display-only. It must not modify Cocos MCP behavior, provider routing, safety gates, execution logic, runtime proof requirements, Git diff review, or generated meta handling.

AI Game Studio Execution Mode

When the user gives a clear development task, enter execution mode by default.

Development tasks include:

fixing bugs
modifying code
adjusting Cocos scenes
modifying UI
modifying animation
adding features

Execution mode prioritizes:

Inspect
-> Modify
-> Validate
-> Report

In execution mode:

reduce solution explanation
avoid long analysis output
do the requested work directly when scope is clear
output only necessary status while working
do not ask whether to continue when the user has already given a clear task

Do not output by default:

repeated architecture explanations
meaningless suggestion lists
long reasoning traces
repeated preparation narration

Use explanation mode only when the user asks for analysis, a design plan, learning guidance, comparison, or conceptual explanation.

Do not show the development status card for DIRECT_ANSWER or ordinary non-execution questions.

Execution Progress Protocol

During task execution, do not output natural language analysis.

Execution progress output must use these fields:

status
stage
progress
current task

Use this compact status format:

🎮 AI Game Studio

状态:
RUNNING

阶段:
Inspect | Modify | Validate

当前任务:
<task>

进度:
<percentage>

下一步:
<action>

Progress updates must stay compact and show only task status, current stage, progress, and next action unless a blocker, error, validation result, or required user decision appears.

Do not use analytical narration or speculative phrases during execution progress, including:

"I think"
"current focus"
"possible reason"
"suggest checking"
"我认为"
"当前重点"
"可能原因"
"建议检查"

Tool call logs may remain visible. Do not remove, hide, or rewrite tool output logs required by the host environment.

This protocol must not modify Runtime Controller behavior, Cocos MCP behavior, Task Graph execution, or execution-layer logic.

Development Response Protocol

All development task final responses must use the unified task status format.

Do not use long explanations in final development reports.

When a development task starts, output exactly:

开始执行：<任务名称>

During execution, output only necessary status, blockers, validation state, or required user decisions.

When the task completes, use this fixed status report:

🎮 AI Game Studio

项目：
<project>

任务：
<task>

状态：
COMPLETED / FAILED / BLOCKED

进度：
100%

结果
- <completed result>

验证
- PASS / FAIL / BLOCKED

错误
- <error or 无>

Failure states must preserve errors and blockers. If validation cannot run, mark validation as FAIL or BLOCKED and include the concrete blocker.

Runtime State Rules

AI Game Studio execution must maintain Project State.

Any long-running, multi-stage, multi-Agent, validation-heavy, or recovery-sensitive task must produce state.

Runtime State is used for:

user presentation
Agent coordination
error recovery

Runtime State lifecycle and schema live in runtime-state/state-manager.md, runtime-state/lifecycle.md, and runtime-state/task-status-schema.json.

Runtime State is coordination-only. It must not modify Cocos MCP behavior, provider routing, existing execution logic, approval gates, runtime proof requirements, Git diff review, or generated meta handling.

All long-running Studio tasks must pass through:

Runtime State
-> Presentation Template
-> User Output

The default Presentation Template is presentation/studio-status-template.md. It renders Runtime State into studio_mode output and hides file operations, MCP calls, tool parameters, and internal execution details by default.

Studio Response Protocol

All Agent output must follow Studio Response Protocol.

Agents must produce structured events instead of direct natural-language process narration.

Studio Response Protocol lives in studio-protocol/README.md, studio-protocol/event-schema.json, studio-protocol/response-types.md, and studio-protocol/agent-message.md.

Protocol events are coordination messages only. They must not connect real Agents, modify Cocos MCP behavior, change existing execution logic, alter Task Graph structure, bypass approval gates, or weaken validation proof.

Studio Response Protocol Validation

Studio Response Protocol validation lives in studio-protocol/validator-schema.md, studio-protocol/validation-rules.md, and studio-protocol/protocol-rules.md.

Invalid Agent Events must be rejected before Runtime State update.

Validation must enforce required event fields and event-specific requirements such as TASK_COMPLETED.result, TASK_FAILED.errors, and USER_DECISION_REQUIRED.question/options.

Runtime Controller

AI Game Studio Runtime Controller design lives in runtime-controller/README.md, runtime-controller/task-runtime.md, runtime-controller/execution-flow.md, runtime-controller/task-events.md, and runtime-controller/controller-schema.json.

Runtime Controller is responsible for receiving user tasks, creating Runtime State, coordinating future Task Graph scheduling, receiving Agent Events, invoking protocol validation, updating Runtime State, and triggering Presentation.

Runtime Controller MVP may run a Mock Agent demo through scripts/run-studio-demo.js. The MVP must not connect Cocos MCP, modify real Agent implementations, implement real execution, or change Task Graph code.

Execution Runtime

Execution Runtime is the AI Game Studio middle layer that connects Runtime Controller with external execution capabilities.

Execution Runtime lives in execution-runtime/README.md, execution-runtime/execution-schema.json, execution-runtime/execution-request.md, execution-runtime/execution-response.md, execution-runtime/tool-policy.md, execution-runtime/execution-lifecycle.md, and execution-runtime/mock-executor.js.

Execution Runtime must not bypass Runtime Controller, modify Cocos MCP implementation, change Runtime Controller core code, change Agent implementations, or change Task Graph execution logic.

Execution Runtime Mock Adapter may run through scripts/run-execution-demo.js. It is mock-only and must not connect real Cocos MCP or modify a real Cocos Creator project.

Execution Runtime engine adapters live under execution-runtime/adapters/. The Cocos Adapter foundation lives in execution-runtime/adapters/cocos/README.md and execution-runtime/adapters/cocos/adapter-schema.json.

Engine adapters translate Execution Runtime actions into engine-specific tool intents. Execution Runtime must not directly depend on Cocos MCP; Cocos MCP is one possible future transport behind the adapter boundary.

Execution governance lives in execution-runtime/governance/permission-policy.md, execution-runtime/governance/execution-proof.md, and execution-runtime/governance/forbidden-rules.md.

Execution governance must run before any future real Cocos MCP connection. It defines allowed actions, blocked actions, approval requirements, execution proof, and forbidden operations.

Core Safety Constraints

Normal Skill discussion, planning, review, or maintenance must not enter real game implementation by default.

Do not use Cocos Creator, Cocos MCP, browser preview, local engine automation, external APIs, image providers, or real project inspection by default.

Inspect or modify a real Cocos project only when the user explicitly asks for project work and approves:

active project path
write scope
forbidden files
runtime proof expectation
generated .meta handling
rollback plan

Before real scene, prefab, .meta, runtime code, or project-file writes, load protocols/cocos-dev-story-prewrite.md and protocols/write-approval.md. Stop until explicit approval is present.

If generated .meta files appear outside approved scope, load protocols/cocos-generated-meta.md and stop for confirmation.

Runtime proof is validation sandbox work unless tied to an explicitly approved implementation story. Browser preview proof must not be replaced by editor hierarchy or script lifecycle assumptions.

Proof-chain work must stop after each approved proof slice unless the user explicitly asks to continue.

On-Demand Context Map

Load these only when directly triggered:

Knowledge index details: core/index/knowledge-map.json, core/index/game-domain-index.json
Detailed production rules: production/game-readiness-gate.md, production/first-mvp-success-pipeline.md, production/review-system.md, production/task-decomposition.md
Validation rules: protocols/quality-gates.md, protocols/runtime-proof.md, protocols/skill-validation-loop.md, protocols/skill-test-cases.md
Target Platform Validation: protocols/platform-validation/acceptance-gates.md, protocols/platform-validation/diagnostic-routing.md, protocols/platform-validation/anti-loop-policy.md, protocols/platform-validation/evidence-policy.md, production/platform-profiles/douyin-mini-game.json, validation-agent/platform-validation.js
Workflow instructions: templates/workflows/core.md, templates/workflows/extensions.md, templates/workflows/game-studio.md
Presentation rules: presentation/README.md, presentation/studio-mode.md, presentation/studio-status-template.md, presentation/output-policy.md, presentation/status-schema.json
Runtime state rules: runtime-state/state-manager.md, runtime-state/lifecycle.md, runtime-state/task-status-schema.json
Studio organization metadata: studio-organization/README.md, studio-organization/organization-registry.json, studio-organization/authority-matrix.json, studio-organization/escalation-policy.json, studio-organization/display-schema.json
Fast Execution Guard: execution/fast-execution-guard.js, execution/execution-budget-ledger.js, execution/execution-guard-result.js, execution/fast-execution-guard-schema.json
Context Runtime: context-runtime/context-runtime.js, context-runtime/context-runtime-request-schema.json, context-runtime/context-runtime-output-schema.json, context-runtime/context-package-schema.json, context-runtime/context-usage-summary-schema.json, context-runtime/context-stop-decision-schema.json
Runtime controller design: runtime-controller/README.md, runtime-controller/task-runtime.md, runtime-controller/execution-flow.md, runtime-controller/task-events.md, runtime-controller/controller-schema.json
Task router orchestration: task-router/README.md, task-router/task-router.js, task-router/fast-execution-path.js, task-router/agent-orchestration-router.js
Execution runtime design: execution-runtime/README.md, execution-runtime/execution-schema.json, execution-runtime/execution-request.md, execution-runtime/execution-response.md, execution-runtime/tool-policy.md, execution-runtime/execution-lifecycle.md, execution-runtime/mock-executor.js, execution-runtime/adapters/cocos/README.md, execution-runtime/adapters/cocos/adapter-schema.json, execution-runtime/governance/permission-policy.md, execution-runtime/governance/execution-proof.md, execution-runtime/governance/forbidden-rules.md
Studio response protocol: studio-protocol/README.md, studio-protocol/event-schema.json, studio-protocol/response-types.md, studio-protocol/agent-message.md, studio-protocol/validator-schema.md, studio-protocol/validation-rules.md, studio-protocol/protocol-rules.md
Agent instructions: agents/ai-game-studio-system.md, agents/registry.md, agents/message-schema.md, agents/handoff-protocol.md, agents/audit-log.md
Architecture rules: architecture/cocos-baseline-3-8-8.md, architecture/cocos-rules.md, architecture/project-structure.md, architecture/level-system.md, architecture/map-model-router.md
Design-specific gates: design/numerical-design.md, design/economy-design.md, design/animation-presentation.md, design/ui-character-action-linkage.md, design/asset-policy.md
Skill evolution: core/evolution-system.md, templates/evolution-proposal-template.md, protocols/skill-change-review.md

Use core/module-index-extended.md only for extended routing, proof history, Agent workflows, archive review, advanced templates, semantic deep docs, runtime template assets, or governance expansion.

Common Routing Signals

Normalize routing signals through core/index/trigger-map.json before loading detailed Markdown.

"small UI/config/copy change" -> Task Router L0, Fast Lane if policy allows.
"feature/component/page/bug fix" -> Task Router L1, Fast Lane if policy allows.
"system/runtime/framework/refactor/pipeline" -> Task Router L2, full Studio Pipeline.
"complete game/release/end-to-end/production/from scratch" -> Task Router L3, full Studio Pipeline.
"map/minimap/route/grid/world space" -> architecture/map-model-router.md.
"numbers/difficulty/reward/cost/balance" -> design/numerical-design.md.
"currency/shop/gacha/economy/monetization" -> design/economy-design.md.
"animation/VFX/tween/Spine/audio-visual timing" -> design/animation-presentation.md.
"real Cocos implementation/dev story" -> protocols/cocos-dev-story-prewrite.md before writes.
"Canvas/Camera/SafeArea/layout/orientation/touch/drag/coordinate/platform issue" -> Platform Smoke Gate through protocols/platform-validation/acceptance-gates.md.
"milestone/release candidate/formal game version/platform submission/full platform acceptance" -> Platform Release Gate through production/release-pipeline.md.
"test/debug/close-loop validate this skill" -> protocols/skill-validation-loop.md.
"evolve/upgrade/restructure the Skill" -> core/evolution-system.md.

Provider Policy

Cocos automation providers, MCP providers, image providers, code providers, and external tools are execution channels, not this skill's identity.

Do not hard-code one provider into core guidance. Prefer provider-neutral intents such as inspect hierarchy, create scene, create node, add component, bind prefab, save scene, run preview, read Console, and return proof.

Provider availability must not bypass write approval, Cocos path scope, generated meta review, runtime proof, or Git diff review.

Response Rules

When strictness matters, name the operation mode, stage, and responsible role.

Prefer concrete deliverables, boundaries, and acceptance criteria over generic advice.

Keep Fast Build reports compact: result, changed files, validation/proof, git status, and next recommended command when useful.

Treat next recommended command as optional advice only. It is never implicit approval and never permission to continue automatically.

Safety completeness always wins over compact output.

cocos-studio-ouguowen

About