t1k:cocos:base:skill-domain-routing

Field	Value
Module	`base`
Version	`3.3.2`
Effort	`low`
Tools	—

Keywords: cocos skill, discover skill, find skill, playable skill, route to skill, routing, skill domain, skill for, skill lookup, skill routing, which skill

How to invoke

/t1k:cocos:base:skill-domain-routing

Skill Domain Routing (theonekit-cocos)

Intent-based discovery for Cocos Creator kit skills — the SSOT for “which t1k-cocos-* skill handles X”. For core T1K skills (cook, fix, plan, etc.), see skills/t1k-help/references/skill-domain-routing.md.

Moved out of .claude/rules/skill-domain-routing-cocos.md on 2026-08-27 (ctx-budget trim), then out of docs/skill-domain-routing-cocos.md into this skill on 2026-08-27 (#332 — a pure lookup table consulted after the agent has already decided to do Cocos work is a skill placement, not a rule and not a loose doc). That rule file is now a short pointer to this skill; /t1k:find-skill also resolves this table by keyword. Unlike a docs/ page, a skill is claimed by a module and gated by npm run check:registry-consistency, so it cannot silently drop out of the release artifact.

This kit ships 69 skills across 3 modules — base (18), playable (46), rushtank (5). Every one of them is listed below. Rows marked theonekit-core ship from another kit.

Module: `base` — Cocos tooling and conventions

Required module — installed with every preset. Applies to any Cocos Creator project, not just playable ads.

Code Conventions & Architecture

User wants to…

Look up naming, @ccclass/@property decorators, the SignalBus named-method rule, lifecycle order, or the Service/Component/Controller split → t1k-cocos-base-code-conventions
Work out why a collision-group bit test (collider.getGroup() & BIT) reads false, or decide whether a group test can replace getComponent → t1k-cocos-base-code-conventions → references/physics-collision-groups.md
Decide whether a pattern (pooling, FSM, SignalBus, component split, service singleton) is mandatory here, or grade a legacy project against its docs/system-design.md → t1k-cocos-base-architecture-patterns
Ask the studio corpus “do we already have this?” — the FIRST prior-art step, run before grepping and before proposing new work — Cocos-scoped doc_search that keeps Unity/.NET members from outranking real Cocos answers → t1k-cocos-base-knowledge-sweep
Structure a feature module, decide where game logic lives, or make logic unit-testable without booting Cocos → t1k-game-arch (theonekit-core, t1k-extended) for the engine-agnostic doctrine + t1k-cocos-base-clean-architecture for the Cocos specialization (composition root, signalBus, ESLint zones, Vitest)

The design doc & its manifest

docs/system-design.md is the handoff contract the rest of the family grades against, so its artifact and its grading are deliberately two skills. Route by which one you need:

You want to…	Skill
Author, migrate, or verify `docs/system-design.md`; generate `docs/design-manifest.json`; resolve the template	`t1k-cocos-base-system-design`
Judge whether the code conforms to it, or which pattern the code is now obliged to use	`t1k-cocos-base-architecture-patterns`
Read the doctrine itself (SOLID, module boundaries, class roles, anti-patterns)	Neither — the project’s own `docs/system-design.md` § Code Structure Rules

User wants to…

Author a design doc from the canonical template, or convert a non-canonical / ASCII-tree doc onto it → t1k-cocos-base-system-design (migrate-design-doc.cjs, report-only by default)
Turn the doc into the machine-readable module map consumers use, or check it still matches the code → t1k-cocos-base-system-design (generate-manifest.cjs, verify-manifest.cjs)
Understand state: as-is | to-be | converged, parse, or priorArt before trusting a manifest → t1k-cocos-base-system-design → references/design-manifest.md (schema SSOT)

architecture-patterns never writes the doc. An absent or stale design doc is a blocking finding it reports and system-design repairs — a skill that both defines the target and grades against it can never report that the target is wrong.

Documentation & Code Graphs

User wants to…

Generate @ccclass class diagrams, a module dependency graph, or a scene/prefab hierarchy; extract TSDoc; audit annotation coverage read-only → t1k-cocos-base-script-graph
Raise TSDoc quality so annotated code is actually discoverable by doc_search (so the reuse scan classifies REUSE instead of missing it) → t1k-cocos-base-doc-flywheel
Run the whole TSDoc chain (audit → author → annotate → export → verify) in one call instead of driving script-graph and doc-flywheel separately → t1k-cocos-base-doc-pass
Work out which t1k-cocos-* skill handles X in the first place → t1k-cocos-base-skill-domain-routing (this skill), or /t1k:find-skill "<query>"

Spine & Skeletal Animation

User wants to…

Work out why a Spine 4.2 physics constraint that reacts in Spine Editor or spine-unity does nothing under sp.Skeleton, pick the Spine runtime version in Feature Cropping, or bridge Node movement into skeleton space → t1k-cocos-base-spine

Assets, Shaders & Materials

User wants to…

Import, validate, rename, or promote assets from _Incoming/ to canonical locations under the asset-pipeline manifest → t1k-cocos-base-asset-import
Hand-author a Cocos 3.8.7 .effect shader, its .mtl material, and the material wiring → t1k-cocos-base-effect-authoring
Port a Unity .shader (Amplify, Shader Forge, hand-written) into a Cocos 3.8.7 port spec → t1k-cocos-base-unity-shader-port

JS→TS Migration (Cocos Creator 2.4.x)

The single JS→TS pipeline. The optional migration module shipped a drifted fork of these six skills and was absorbed into base on 2026-08-15; t1k-cocos-migration-* no longer resolves.

User wants to…

Run the full 5-phase pipeline (PRECONDITION → CONVERT → VALIDATE → ATTACH → verify), stateful and idempotent with stop-the-world rollback → t1k-cocos-base-migrate
Build the require-graph, Export-Form Registry, and component-name graph the pipeline reads → t1k-cocos-base-dep-graph
Codemod one .js into a coexistence .cv.ts (ts-morph) → t1k-cocos-base-js2ts
Gate the converted file with the TypeScript version pinned to the editor bundle → t1k-cocos-base-tsc-validate
Rewrite string-name component lookups (getComponent("Foo") and friends) for JS/TS coexistence → t1k-cocos-base-compref
Attach a .cv.ts component to a prefab/scene without deleting the JS (.meta + UUID re-point) → t1k-cocos-base-uuid-verify

The TypeScript version is pinned in t1k-cocos-base-tsc-validate/scripts/package.json — default 4.1.3 (what Cocos Creator 2.4.x bundles). Change that dependency if your editor bundles another version; the gate prints the resolved ts.version at runtime.

Module: `playable` — the playable-ad runtime

Optional module (requires base). The largest module: 45 skills.

Game Architecture & Lifecycle

User wants to…

Set up game flow states (boot, loading, gameplay, end card, CTA, audio) → t1k-cocos-playable-gameflow
Manage object lifecycle, init order, and teardown for non-Component systems → t1k-cocos-playable-lifecycle
Implement a finite state machine with decorator registration and async transitions → t1k-cocos-playable-fsm

Input & Controls

User wants to…

Set up touch detection, gesture recognition, or 3D raycasting → t1k-cocos-playable-input-service

UI & Layout

User wants to…

Build adaptive canvas layouts for portrait/landscape — aspect-ratio detection, safe-area insets → t1k-cocos-playable-layout
Show pooled toast notifications and UI feedback → t1k-cocos-playable-toast
Implement screen transitions between game states (fade, slide, scale, curtain) → t1k-cocos-playable-transitions
Drive interactive tutorials and step-by-step animated hints → t1k-cocos-playable-tutorials
Build a UI prefab from a reference image, reusing existing project UI/assets → t1k-cocos-playable-ui-from-image
Localize the game end-to-end: scan scene/prefab/config/dynamic text, generate locale tables, validate placeholders and font glyphs → t1k-cocos-playable-localize

Animation, VFX & Feel

User wants to…

Author reusable flying-animation clips with object-pool integration → t1k-cocos-playable-animation-core
Use preset animation sequences (bounce, shake, pop — 20 presets) or register custom ones → t1k-cocos-playable-animation-presets
Add juice to existing tweens and to bare show/hide with @playablelabs/motion → t1k-cocos-playable-juice
Measure / fit / center / hit-test a runtime-loaded sp.Skeleton — uploaded spine renders at the wrong size, sits off-center, is untappable, or its outline thickness varies per object → t1k-cocos-playable-spine-fit
Convert a Unity ParticleSystem prefab into a Cocos 3.8.7 cc.ParticleSystem → t1k-cocos-playable-unity-particle
Make a 3D cc.ParticleSystem render under a Canvas (2D/UI space) → t1k-cocos-playable-particle-ui

Progression & Scoring

User wants to…

Track level progression and scale difficulty per level → t1k-cocos-playable-progression
Compute and display score, combos, and flying reward effects → t1k-cocos-playable-score

Performance & Communication

User wants to…

Pool and recycle prefabs — spawn/recycle lifecycle, category organization → t1k-cocos-playable-object-pool
Use async/await utilities and cancellation tokens → t1k-cocos-playable-async-utilities
Decouple systems with a type-safe SignalBus → t1k-cocos-playable-signalbus
Wire fonts globally or per-label → t1k-cocos-playable-font-service
Reach for pure math/data helpers (Math, Array, Vec, Coordinate, Time) → t1k-cocos-playable-utilities

Asset Management & Build

User wants to…

Load, cache, and de-duplicate typed resources against a size budget → t1k-cocos-playable-asset-management
Reduce build size: engine module pruning, texture/mesh compression, ad-network budget compliance → t1k-cocos-playable-build-size
Integrate an ad-network SDK (TheOne, Voodoo), postMessage parameter updates, CTA routing → t1k-cocos-playable-sdk-core
Use custom editor scripts, the config watcher, or the Cocos MCP server tools → t1k-cocos-playable-editor-tools

Parameter System (dashboard-tunable config)

Start at the orchestrator; it routes to the rest.

User wants to…

Run parameter discovery → implementation → wiring end-to-end → t1k-cocos-playable-parameter (orchestrator)
Scan the scene Canvas or *Config.ts files for tunable candidates → t1k-cocos-playable-parameter-scan
Decide the node shape / preset for a grouped node (Button, Image, Text, CurrencyUI, HPBar, Countdown) → t1k-cocos-playable-parameter-composite
Generate the flat-primitive PlayableConfig entries and typed ParameterController wiring → t1k-cocos-playable-parameter-implement
Assign scene node UUIDs to @property references over MCP → t1k-cocos-playable-parameter-mcp
Find DEAD parameters — defined but never wired, no-op onUpdate, or wired to a missing @property → t1k-cocos-playable-parameter-audit
Produce the operator-facing parameter guide (XLSX + DOCX) → t1k-cocos-playable-parameter-guide
Draft AI-context entries (description, aliases, aiHints, examples) for PlayableConfigMeta → t1k-cocos-playable-pla-gen-metadata

Modularize — legacy project → CPM packages

Start at the orchestrator; the four pillars run in order.

User wants to…

Audit and modularize a legacy playable toward the @playablelabs CPM model → t1k-cocos-playable-modularize (orchestrator; Phase 0 authors or audits docs/system-design.md)
Pillar A — grade the folder layout against the PlayableAdsTemplate blueprint (R1–R10) → t1k-cocos-playable-modularize-structure-audit
Pillar B — classify each local subsystem REUSE / EXTEND / KEEP / CONTRIBUTE against the published packages → t1k-cocos-playable-modularize-reuse-scan
Phase 2.5 — decide the TARGET module architecture: slice a revised to-be design from the as-is doc + architecture-audit.json + reuse-scan.json. This is the only step that says what modules the system should have → t1k-cocos-playable-preproduction (refactor mode — steps 1, 3, 4, 5, 7 are switched off; no estimate unless asked)
Pillar C — synthesize the audits into one ordered refactor plan → t1k-cocos-playable-modularize-refactor
Pillar D — contribute local work back to the @playablelabs library (ADD or EXTEND) → t1k-cocos-playable-modularize-contribute
Cut a gameplay folder from by-type into vertical mechanic folders, make a mechanic copy-pasteable into another game, or split a god class into a portable slice → t1k-cocos-playable-mechanic-split
Migrate off the PLAGameFoundation / PlayableParamterTool git submodules to the vendored packages → t1k-cocos-playable-submodule-to-package

Boundary — modularize vs mechanic-split: the two overlap on “refactor gameplay code”. t1k-cocos-playable-modularize is the entry point for a project in the CPM pipeline — it owns the design doc, the package reuse, and Tier 2.6, which delegates the mechanic moves. t1k-cocos-playable-mechanic-split is the in-place vertical-slice executor — invoked by Tier 2.6, or standalone on a project not in the pipeline. No packaging, no publishing.

Competitor Analysis, Estimation & Target Design

User wants to…

Reverse-engineer a competitor playable from its URL into gameplay / code-structure / implementation docs → t1k-cocos-playable-extract
Scope a playable before code exists — grill the spec, sweep prior art, obtain the system design, slice it into modules, and cost it (work-package breakdown, reuse discount, Base/Worst two-point model). Still the answer for “estimate”, “quote”, “how long will this take” → t1k-cocos-playable-preproduction
Decide the target module structure for an existing codebase — “what modules should this have”, “design the refactor target”, “slice the target modules”. Same slicing procedure, different input; emits a revised to-be doc, not a quote → t1k-cocos-playable-preproduction (refactor mode — also reachable as t1k-cocos-playable-modularize Phase 2.5 above)

Production Pipeline — Plane tracking & Jenkins builds

User wants to…

Log an agreed breakdown or an estimate report to Plane as a work-item tree, bind the repo to its client project + playable module, check the module against the required-task set, and create the playable’s Jenkins build job → t1k-cocos-playable-pipeline
Understand why work-item titles read Client|Playable|Task rather than core’s [Discipline][Kind] Title → t1k-cocos-playable-pipeline → references/hierarchy-contract.md

Boundary: this skill is an orchestrator. Plane lifecycle mechanics (binding, state resolution by group, the 4-hour leaf cap, guarded writes) stay in core’s t1k-plane; Jenkins config.xml mechanics stay in core’s t1k-jenkins-job. Route a pure Plane or pure Jenkins question to those directly — reach for this skill only when the two must meet on one playable.

Tooling Repair

User wants to…

Work around a Cocos MCP or Write-tool gotcha (project targeting, manage_asset url param, .meta generation, binding a prefab component without the editor) → t1k-cocos-playable-tooling-gotchas
Fix a bug in the Cocos MCP Server extension itself — reproduce over HTTP, failing test, rebuild, reload, PR on the server repo → t1k-cocos-playable-mcp-fix

Module: `rushtank` — RusTank / Epic Idle War content authoring

Optional module (requires base). Game-specific authoring for one Cocos Creator 2.4.15 title.

User wants to…

Add a new backpack equipment item — 4-level trait tree, cost/HP curve, localization, distribution → t1k-cocos-rushtank-add-equipment
Add a new drivable player tank — define, scaling table, star traits, and the hard-coded v1/v3 spots a 4th+ vehicle falls through → t1k-cocos-rushtank-add-player-tank
Add or manage a texture-swap entity variant (reuse an existing DragonBones skeleton + AI with different art) → t1k-cocos-rushtank-entity-variant
List, fetch, create, update, or comment on tasks via the configured provider → t1k-cocos-rushtank-task-framework
Turn a phased implementation plan into tasks in that provider → t1k-cocos-rushtank-plan-tasks

Notes

All skills above are Cocos-kit skills; invoke via the Skill tool — except t1k-game-arch, which ships from theonekit-core’s t1k-extended module (a hard dependency of cocos:base, so it is always installed alongside this kit).
Module directories are unprefixed: base, playable, rushtank. Skill IDs carry the prefix — t1k-cocos-{module}-{slug}, slash-form t1k:cocos:{module}:{slug}. There is no cocos-playable module; that spelling is historical and does not resolve.
Only base is required. playable and rushtank are opt-in — a skill listed under a module you have not installed will not be available.

Keep this file complete

Every skill in .claude/modules/*/module.json must appear here. Coverage check:

node -e '
const fs=require("fs");
const routing=fs.readFileSync(".claude/modules/base/skills/t1k-cocos-base-skill-domain-routing/SKILL.md","utf8");
const all=[];
for (const m of fs.readdirSync(".claude/modules")) {
  JSON.parse(fs.readFileSync(".claude/modules/"+m+"/module.json","utf8"))
    .skills.forEach(s=>all.push([m,s]));
}
const missing=all.filter(([,s])=>!routing.includes(s));
console.log("missing from routing:", missing.length, "/", all.length);
missing.forEach(([m,s])=>console.log(" ", m, s));
'

It must print 0 / <total>. Run it after adding any skill.

t1k:cocos:base:skill-domain-routing

How to invoke

Skill Domain Routing (theonekit-cocos)

Module: base — Cocos tooling and conventions

Code Conventions & Architecture

The design doc & its manifest

Documentation & Code Graphs

Spine & Skeletal Animation

Assets, Shaders & Materials

JS→TS Migration (Cocos Creator 2.4.x)

Module: playable — the playable-ad runtime

Game Architecture & Lifecycle

Input & Controls

UI & Layout

Animation, VFX & Feel

Progression & Scoring

Performance & Communication

Asset Management & Build

Parameter System (dashboard-tunable config)

Modularize — legacy project → CPM packages

Competitor Analysis, Estimation & Target Design

Production Pipeline — Plane tracking & Jenkins builds

Tooling Repair

Module: rushtank — RusTank / Epic Idle War content authoring

Notes

Keep this file complete

Module: `base` — Cocos tooling and conventions

Module: `playable` — the playable-ad runtime

Module: `rushtank` — RusTank / Epic Idle War content authoring