[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KG0WBX9B57Z015TMHWCDA4":3,"skill-same:01M6KG0WBX9B57Z015TMHWCDA4":80},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":58,"commitSha":59,"skillDirectory":60,"forksCount":61,"repositoryHtmlUrl":62,"repositoryHomepageUrl":6,"ownerHtmlUrl":63,"ownerBlogUrl":6,"ownerDescription":64,"updatedAt":65,"install":66,"resources":79},"01M6KG0WBX9B57Z015TMHWCDA4","unity-dots-best-practices",null,"Unity DOTS, ECS, Jobs, and Burst guidance for scalable runtime systems. Core best-practices covering components, systems, bakers, blob assets, scheduling, structural change costs, and performance-sensitive simulation patterns for Entities 1.3+.","dyCuong03\u002Funity-agent-team","dyCuong03","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F137050365?v=4","01M6KFXC85HQHXZJC2VC1KY6EZ","CuongND","01M6KFXCCHP6CD5MTA8NECJC36",8,"MIT","https:\u002F\u002Fgithub.com\u002FdyCuong03\u002Funity-agent-team\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Funity-dots-best-practices\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"unity dots best practices","unity","best practices","simulation","ecs","Scalable","false","structural","windsurf","patterns","knowledge","writing","code","packages","tasks","copilot","architecture","change","components","performance","2026-11-10 10:12:30",false,"---\nname: unity-dots-best-practices\ndescription: Unity DOTS, ECS, Jobs, and Burst guidance for scalable runtime systems. Core best-practices covering components, systems, bakers, blob assets, scheduling, structural change costs, and performance-sensitive simulation patterns for Entities 1.3+.\nuse-when: |\n  Load for unity-dots-dev on any DOTS or Hybrid domain task. Always included as P1\n  knowledge for architect and unity-dots-dev. Load when writing ISystem, IJobEntity,\n  Baker, blob assets, ECB, or any ECS architecture decisions.\ndo-not-use-when: |\n  Do not load for the unity-dev classic lane (MonoBehaviour tasks). Do not load for\n  tester or verifier roles. Not needed for pure editor-tooling with no runtime ECS.\nplatforms: [claude-code, codex, copilot, cursor, windsurf]\nmetadata:\n  source: https:\u002F\u002Fdocs.unity3d.com\u002FPackages\u002Fcom.unity.entities@1.3\n  version: 1.3.8\n  tier: 1\n  user-invocable: false\ntask-categories: [ecs, performance, burst, jobs, dots]\n\n---\n\n# Unity DOTS Best Practices\n\nWhen working on Unity DOTS runtime code, design and verify against these constraints. See `@.claude\u002Fdocs\u002Fmcp-integration.md` for `ai-game-developer` and `agentmemory` tool usage.\n\n## Design Principles\n\n- Design around **data layout and access patterns first**.\n- Prefer `IComponentData`, `IBufferElementData`, `BlobAssetReference\u003CT>`, `IAspect`, `ISystem`, Burst, and jobs where they clearly improve scale and maintainability.\n- Keep hot paths **allocation-free** — no managed objects in simulation code.\n- Minimize **structural changes** inside frequently executed loops.\n- Treat **archetype churn**, **sync points**, and **main-thread fallbacks** as explicit costs, not background noise.\n- Keep **authoring\u002Fbaker code separate** from runtime systems (asmdef boundaries).\n- Make **update order and ownership** explicit. Never imply ordering.\n- Prefer **deterministic, debuggable data flow** over implicit side effects.\n\n## Component & Buffer Design\n\n- One concern per component. Don't pack unrelated fields just because they share an entity.\n- `IBufferElementData` for variable-size per-entity data; cap with `InternalBufferCapacity` thoughtfully.\n- `BlobAssetReference\u003CT>` for large, immutable, shared data (e.g., level configs, ability data).\n- `IEnableableComponent` for state toggles that would otherwise cause add\u002Fremove churn.\n- Avoid managed components except for editor-bridging cases.\n\n## System Design\n\n- Prefer `ISystem` (Burst-compilable) over `SystemBase` for hot paths.\n- Use `SystemAPI` for queries, singletons, time, lookups — keeps intent explicit.\n- Explicit `[UpdateInGroup]`, `[UpdateAfter]`, `[UpdateBefore]` — never rely on implicit ordering.\n- Keep system responsibilities narrow. Compose, don't merge.\n\n## Job Design\n\n- `IJobEntity` for per-entity work where chunk access is not needed.\n- `IJobChunk` when you need chunk-level batching, change filtering, or component lookup optimization.\n- `EntityCommandBuffer` for structural changes, with intentional playback point.\n- `EntityCommandBuffer.ParallelWriter` for parallel structural changes — pass `sortKey` correctly.\n- Manage `Dependency` explicitly when chaining multiple jobs.\n\n## Burst Compatibility\n\n- No managed references, no virtual dispatch, no `string`, no `throw` in hot loops.\n- `BurstCompile` everything that can be Burst-compiled. Address compilation failures immediately.\n- `[BurstCompile(CompileSynchronously = true)]` for tests so failures surface in CI.\n\n## NativeContainers\n\n- Allocator choice: `Allocator.Temp` (single frame, main thread), `Allocator.TempJob` (≤4 frames), `Allocator.Persistent` (long-lived).\n- Always dispose. Use `using` or explicit `.Dispose()` in `OnDestroy`.\n- Pass `[ReadOnly]` and `[WriteOnly]` attributes to enable parallelism.\n\n## Self-Check Before Finalizing\n\n1. Is the data representation aligned with read\u002Fwrite patterns?\n2. Are there avoidable sync points? (`EntityManager.CompleteAllTrackedJobs`, `.GetSingleton`, structural changes outside ECB)\n3. Are structural changes limited and intentional?\n4. Is this Burst\u002Fjob friendly? Any non-Burst-compatible types?\n5. Will the approach scale to large entity counts (target: 10k–100k)?\n6. Have I memoized any per-frame allocations into job-owned containers?\n7. Have I confirmed Unity-side state with `mcp__ai-game-developer__gameobject-component-get` (for authoring) or `tests-run` (for behavior)?\n8. Have I saved a `memory_lesson_save` for non-obvious decisions?\n\n## Anti-Patterns\n\n- `EntityManager.CreateEntity` \u002F `AddComponent` inside `OnUpdate` without ECB\n- Capturing managed lambdas in `SystemBase.Entities.ForEach` hot paths\n- Using `SystemBase` where `ISystem` would work\n- Implicit system ordering (\"it happens to run before X\")\n- Buffers used as unbounded queues without consume logic\n- One giant component that everyone reads and writes\n- Manager-pattern singletons disguised as ECS singletons\n","# Unity DOTS Best Practices\n\nWhen working on Unity DOTS runtime code, design and verify against these constraints. See `@.claude\u002Fdocs\u002Fmcp-integration.md` for `ai-game-developer` and `agentmemory` tool usage.\n\n## Design Principles\n\n- Design around **data layout and access patterns first**.\n- Prefer `IComponentData`, `IBufferElementData`, `BlobAssetReference\u003CT>`, `IAspect`, `ISystem`, Burst, and jobs where they clearly improve scale and maintainability.\n- Keep hot paths **allocation-free** — no managed objects in simulation code.\n- Minimize **structural changes** inside frequently executed loops.\n- Treat **archetype churn**, **sync points**, and **main-thread fallbacks** as explicit costs, not background noise.\n- Keep **authoring\u002Fbaker code separate** from runtime systems (asmdef boundaries).\n- Make **update order and ownership** explicit. Never imply ordering.\n- Prefer **deterministic, debuggable data flow** over implicit side effects.\n\n## Component & Buffer Design\n\n- One concern per component. Don't pack unrelated fields just because they share an entity.\n- `IBufferElementData` for variable-size per-entity data; cap with `InternalBufferCapacity` thoughtfully.\n- `BlobAssetReference\u003CT>` for large, immutable, shared data (e.g., level configs, ability data).\n- `IEnableableComponent` for state toggles that would otherwise cause add\u002Fremove churn.\n- Avoid managed components except for editor-bridging cases.\n\n## System Design\n\n- Prefer `ISystem` (Burst-compilable) over `SystemBase` for hot paths.\n- Use `SystemAPI` for queries, singletons, time, lookups — keeps intent explicit.\n- Explicit `[UpdateInGroup]`, `[UpdateAfter]`, `[UpdateBefore]` — never rely on implicit ordering.\n- Keep system responsibilities narrow. Compose, don't merge.\n\n## Job Design\n\n- `IJobEntity` for per-entity work where chunk access is not needed.\n- `IJobChunk` when you need chunk-level batching, change filtering, or component lookup optimization.\n- `EntityCommandBuffer` for structural changes, with intentional playback point.\n- `EntityCommandBuffer.ParallelWriter` for parallel structural changes — pass `sortKey` correctly.\n- Manage `Dependency` explicitly when chaining multiple jobs.\n\n## Burst Compatibility\n\n- No managed references, no virtual dispatch, no `string`, no `throw` in hot loops.\n- `BurstCompile` everything that can be Burst-compiled. Address compilation failures immediately.\n- `[BurstCompile(CompileSynchronously = true)]` for tests so failures surface in CI.\n\n## NativeContainers\n\n- Allocator choice: `Allocator.Temp` (single frame, main thread), `Allocator.TempJob` (≤4 frames), `Allocator.Persistent` (long-lived).\n- Always dispose. Use `using` or explicit `.Dispose()` in `OnDestroy`.\n- Pass `[ReadOnly]` and `[WriteOnly]` attributes to enable parallelism.\n\n## Self-Check Before Finalizing\n\n1. Is the data representation aligned with read\u002Fwrite patterns?\n2. Are there avoidable sync points? (`EntityManager.CompleteAllTrackedJobs`, `.GetSingleton`, structural changes outside ECB)\n3. Are structural changes limited and intentional?\n4. Is this Burst\u002Fjob friendly? Any non-Burst-compatible types?\n5. Will the approach scale to large entity counts (target: 10k–100k)?\n6. Have I memoized any per-frame allocations into job-owned containers?\n7. Have I confirmed Unity-side state with `mcp__ai-game-developer__gameobject-component-get` (for authoring) or `tests-run` (for behavior)?\n8. Have I saved a `memory_lesson_save` for non-obvious decisions?\n\n## Anti-Patterns\n\n- `EntityManager.CreateEntity` \u002F `AddComponent` inside `OnUpdate` without ECB\n- Capturing managed lambdas in `SystemBase.Entities.ForEach` hot paths\n- Using `SystemBase` where `ISystem` would work\n- Implicit system ordering (\"it happens to run before X\")\n- Buffers used as unbounded queues without consume logic\n- One giant component that everyone reads and writes\n- Manager-pattern singletons disguised as ECS singletons\n",{"name":5,"metadata":44,"use-when":48,"platforms":49,"description":7,"do-not-use-when":53,"task-categories":54},{"tier":45,"source":46,"version":47,"user-invocable":40},1,"https:\u002F\u002Fdocs.unity3d.com\u002FPackages\u002Fcom.unity.entities@1.3","1.3.8","Load for unity-dots-dev on any DOTS or Hybrid domain task. Always included as P1\nknowledge for architect and unity-dots-dev. Load when writing ISystem, IJobEntity,\nBaker, blob assets, ECB, or any ECS architecture decisions.\n",[50,51,34,52,27],"claude-code","codex","cursor","Do not load for the unity-dev classic lane (MonoBehaviour tasks). Do not load for\ntester or verifier roles. Not needed for pure editor-tooling with no runtime ECS.\n",[23,38,55,56,57],"burst","jobs","dots","main","fe4746b9f07e6c7c2b6d3932002183af9b9f6fa2",".claude\u002Fskills\u002Funity-dots-best-practices",0,"https:\u002F\u002Fgithub.com\u002FdyCuong03\u002Funity-agent-team","https:\u002F\u002Fgithub.com\u002FdyCuong03","Game developer","2026-07-25 22:22:25",{"source":8,"skillName":5,"commands":67,"prompt":77,"zipAvailable":78},[68,71,74],{"tool":69,"command":70},"npx","npx skills add dyCuong03\u002Funity-agent-team --skill unity-dots-best-practices",{"tool":72,"command":73},"bunx","bunx skills add dyCuong03\u002Funity-agent-team --skill unity-dots-best-practices",{"tool":75,"command":76},"pnpm","pnpm dlx skills add dyCuong03\u002Funity-agent-team --skill unity-dots-best-practices","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FdyCuong03\u002Funity-agent-team\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Funity-dots-best-practices\u002FSKILL.md",true,[],[81,104,126,151,170,189],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":39},"01M6KH55FFS00ET877QSMRYGX4","dots-update-groups","How to choose the right ECS system group and ordering so per-frame and per-fixed-step work is deterministic and never races its own readers. Covers InitializationSystemGroup \u002F SimulationSystemGroup \u002F PresentationSystemGroup \u002F FixedStepSimulationSystemGroup \u002F VariableRateSimulationSystemGroup, UpdateBefore \u002F UpdateAfter peer ordering, OrderFirst \u002F OrderLast group-boundary placement, RateManager, and the cross-group ordering trap. Use when adding an ISystem, fixing \"value visible one frame late\" bugs, or coupling simulation to a fixed timestep.","https:\u002F\u002Fgithub.com\u002FdyCuong03\u002Funity-agent-team\u002Fblob\u002Fmain\u002Fworkspace\u002Fdots-program\u002Fscratch\u002Fwave-2-orchestrator-drafts\u002Fdots-update-groups\u002FSKILL.md",[],[88,89,90,22,91,92,93,94,95,96,97,98,99,100,23,101,102,103],"update","dots update groups","boundary","how","system","choose","work","use","never","peer","deterministic","how to","coupling","bugs","frame","value",{"skillNo":105,"name":106,"nameZh":6,"description":107,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":108,"categories":109,"keywords":110,"publishedAt":39},"01M6KH50PWYEFQDCGYBZ0326F1","dots-transform-patterns","The Entities 1.x transform model — LocalTransform (writable input) vs LocalToWorld (system-owned matrix), Parent\u002FChild hierarchy, reparenting cost, uniform vs non-uniform scale (PostTransformMatrix), and when to opt out with custom transform systems. Use when designing parent\u002Fchild hierarchies, runtime reparenting (mount\u002Fdismount\u002Fsocket), or choosing transform components at the Baker boundary.","https:\u002F\u002Fgithub.com\u002FdyCuong03\u002Funity-agent-team\u002Fblob\u002Fmain\u002Fworkspace\u002Fdots-program\u002Fscratch\u002Fwave-2-orchestrator-drafts\u002Fdots-transform-patterns\u002FSKILL.md",[],[28,111,112,37,90,92,113,114,95,115,116,117,118,119,120,121,122,123,124,125],"transform","dots transform patterns","mount","model","cost","runtime","systems","input","with","matrix","socket","at","child","custom","hierarchy",{"skillNo":127,"name":128,"nameZh":6,"description":129,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":130,"categories":131,"keywords":137,"publishedAt":39},"01M6KH4VW4MA14DQW4KQYPFT0S","dots-singleton-patterns","Model cross-system shared configuration and game state as a single-entity component with a strict single-writer contract. Covers RequireForUpdate gating, SystemAPI.GetSingleton \u002F GetSingletonRW \u002F HasSingleton \u002F TryGetSingleton, bake-time vs runtime-created vs ECB-system singletons, the \"exactly one entity\" runtime invariant, and the single-writer rule. Use when designing frame-stable global config, shared mutable state, or any component intended to exist on exactly one entity.","https:\u002F\u002Fgithub.com\u002FdyCuong03\u002Funity-agent-team\u002Fblob\u002Fmain\u002Fworkspace\u002Fdots-program\u002Fscratch\u002Fwave-2-orchestrator-drafts\u002Fdots-singleton-patterns\u002FSKILL.md",[132],{"categoryNo":133,"categoryName":134,"taxonomyType":135,"taxonomyTypeDesc":136},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[28,138,139,140,141,142,143,92,114,95,144,145,146,116,147,148,119,102,149,150],"singleton","dots singleton patterns","component","config","state","game","writer","time","shared","contract","as","ecb","gating",{"skillNo":152,"name":153,"nameZh":6,"description":154,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":155,"categories":156,"keywords":157,"publishedAt":39},"01M6KH4PR076AYNDZHD63HHWX6","dots-hybrid-bridge","The one-way bridge between DOTS-owned runtime state and Unity-owned presentation. Covers UnityObjectRef for managed asset refs in components, the DOTS-writes \u002F Unity-reads ownership rule, when to use managed IComponentData vs UnityObjectRef vs CompanionComponent, baker-bridge vs runtime-bridge, and SubScene boundary rules. Use when an entity must reference Unity assets (Mesh, Material, AudioClip, ScriptableObject), a MonoBehaviour view must read entity state, or input\u002FUI must trigger ECS work.","https:\u002F\u002Fgithub.com\u002FdyCuong03\u002Funity-agent-team\u002Fblob\u002Fmain\u002Fworkspace\u002Fdots-program\u002Fscratch\u002Fwave-2-orchestrator-drafts\u002Fdots-hybrid-bridge\u002FSKILL.md",[],[158,159,160,161,37,142,90,162,163,94,164,165,95,116,166,20,118,167,168,169],"bridge","hybrid","dots hybrid bridge","mesh","assets","Rules","read","view","trigger","material","for","managed",{"skillNo":171,"name":172,"nameZh":6,"description":173,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":174,"categories":175,"keywords":176,"publishedAt":39},"01M6KH4FGRQ9AP2ND5H5HX4D83","dots-event-driven-ecs","Model one-frame events and external requests in ECS without dual ownership, polling, or persistent state leaks. Covers request-tag pattern with ECB, enableable command components (no structural change), event buffers (IBufferElementData), explicit consumer ownership, one-frame latency rules, and the banned C# event \u002F UnityEvent \u002F static bus anti-patterns. Use when input\u002FUI\u002Fnetwork must trigger ECS work, when a one-frame signal fans out to N consumers (damage, hit, collision), or when state changes must be processed exactly once.","https:\u002F\u002Fgithub.com\u002FdyCuong03\u002Funity-agent-team\u002Fblob\u002Fmain\u002Fworkspace\u002Fdots-program\u002Fscratch\u002Fwave-2-orchestrator-drafts\u002Fdots-event-driven-ecs\u002FSKILL.md",[],[177,178,23,179,180,37,36,181,182,114,94,183,184,28,185,26,118,186,187,188],"event driven","driven","event","dots event driven ecs","ui","network","command","anti-patterns","pattern","events","static","request",{"skillNo":190,"name":191,"nameZh":6,"description":192,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":193,"categories":194,"keywords":206,"publishedAt":39},"01M6KH4BWRGCEBJ8PKCKCSGT33","valid_skill","A complete, well-formed test fixture skill for SkillHub validation testing. Covers basic task routing and code review for Unity projects.","https:\u002F\u002Fgithub.com\u002FdyCuong03\u002Funity-agent-team\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Fvalid_skill\u002FSKILL.md",[195,200,203],{"categoryNo":196,"categoryName":197,"taxonomyType":198,"taxonomyTypeDesc":199},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":201,"categoryName":202,"taxonomyType":198,"taxonomyTypeDesc":199},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":204,"categoryName":205,"taxonomyType":198,"taxonomyTypeDesc":199},"01JBSEEDCAT000000000000023","Skill与智能体开发",[207,208,209,210,211,212,213,31,214,215,216,217,218,219,20,220,168],"valid skill","valid","code review","testing","review","test","routing","validation","projects","fixture skill","task","fixture","basic","complete"]