[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6KH4VW4MA14DQW4KQYPFT0S":3,"skill-same:01M6KH4VW4MA14DQW4KQYPFT0S":71},{"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":23,"publishedAt":44,"linkOnly":45,"markdownContent":46,"markdownBody":47,"frontMatter":48,"refName":49,"commitSha":50,"skillDirectory":51,"forksCount":52,"repositoryHtmlUrl":53,"repositoryHomepageUrl":6,"ownerHtmlUrl":54,"ownerBlogUrl":6,"ownerDescription":55,"updatedAt":56,"install":57,"resources":70},"01M6KH4VW4MA14DQW4KQYPFT0S","dots-singleton-patterns",null,"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.","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\u002Fworkspace\u002Fdots-program\u002Fscratch\u002Fwave-2-orchestrator-drafts\u002Fdots-singleton-patterns\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000037","律师与法务","PROFESSION","适用职业",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43],"dots singleton patterns","singleton","patterns","shared","gating","ecb","frame","with","as","contract","runtime","component","time","writer","use","model","system","game","state","config","2026-11-10 10:12:30",false,"---\nname: dots-singleton-patterns\ndescription: 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.\n---\n\n# Singleton Patterns — Senior Patterns\n\nA \"singleton\" in DOTS is a component on **exactly one entity**, accessed through a uniform API. It is not a static field, not a `World.GetOrCreate\u003CT>`, and not a service locator. Misuse is silent until the day a second entity gets the component and the system throws on `GetSingleton`.\n\n## Intent\n\nShare a single piece of state across many systems with one declared writer, one well-defined creation point, and a runtime invariant (one and only one).\n\n## Three creation pathways (pick one per singleton, document it)\n\n| Pathway | When | Mutability |\n|---|---|---|\n| **Bake-time** (Authoring + Baker writes one entity in the subscene) | Frame-stable config: game settings, level parameters, level-load seed | Immutable at runtime (treat as `readonly`) |\n| **Runtime-created** (`state.EntityManager.CreateEntity` + `AddComponent` in `OnCreate` of an owner system) | Mutable game state: current input snapshot, level-loaded flag, frame stats | One owner writes; others read |\n| **ECB-system singleton** (`EndSimulationEntityCommandBufferSystem.Singleton` etc.) | Built-in: ECB recorder handles | Read-only handle, never written by user code |\n\n## Senior pattern\n\n```csharp\n\u002F\u002F Component carries data; nothing on it forces uniqueness — the contract is enforced\n\u002F\u002F by your code paths, NOT by a type-system marker.\npublic struct LevelConfig : IComponentData\n{\n    public int   LevelIndex;\n    public float Gravity;\n    public uint  Seed;\n}\n\npublic partial struct GravitySystem : ISystem\n{\n    [BurstCompile]\n    public void OnCreate(ref SystemState state)\n    {\n        \u002F\u002F Declares \"we need this singleton\" — system idles cleanly until it exists.\n        \u002F\u002F Without this, GetSingleton\u003CLevelConfig>() throws if the singleton is missing.\n        state.RequireForUpdate\u003CLevelConfig>();\n    }\n\n    [BurstCompile]\n    public void OnUpdate(ref SystemState state)\n    {\n        \u002F\u002F Read path — safe because RequireForUpdate guarantees existence.\n        var cfg = SystemAPI.GetSingleton\u003CLevelConfig>();\n\n        \u002F\u002F Hot path: capture into job, don't call SystemAPI from inside the job.\n        new ApplyGravityJob { Gravity = cfg.Gravity, Dt = SystemAPI.Time.DeltaTime }\n            .ScheduleParallel();\n    }\n}\n\n\u002F\u002F Mutation: ONE owner system writes via GetSingletonRW. Mark single-writer in code review.\npublic partial struct LevelClockSystem : ISystem\n{\n    [BurstCompile]\n    public void OnUpdate(ref SystemState state)\n    {\n        var cfgRef = SystemAPI.GetSingletonRW\u003CLevelConfig>();\n        cfgRef.ValueRW.Seed = cfgRef.ValueRO.Seed + 1u;\n    }\n}\n```\n\n## Optional \u002F nullable singletons\n\nWhen the singleton may not exist (level not loaded yet, ECB system not available):\n\n```csharp\nif (SystemAPI.HasSingleton\u003CLevelConfig>())\n{\n    var cfg = SystemAPI.GetSingleton\u003CLevelConfig>();\n    \u002F\u002F ...\n}\n\n\u002F\u002F Or:\nif (SystemAPI.TryGetSingleton\u003CLevelConfig>(out var cfg)) { \u002F* ... *\u002F }\n```\n\nPrefer `RequireForUpdate\u003CT>` over runtime `HasSingleton` checks — it gates the whole `OnUpdate`, saves the dispatch when not present, and documents intent.\n\n## Anti-patterns\n\n- ❌ Two systems calling `GetSingletonRW\u003CT>` on the same component. Single-writer contract violation. Code review must reject — even if both writers happen to write the same value, the dependency graph becomes a race.\n- ❌ Iterating an `EntityQuery` to find \"the one entity\" instead of `SystemAPI.GetSingletonEntity\u003CT>()`. Slower and breaks if a second entity ever appears.\n- ❌ Putting hot per-frame per-entity data on a singleton just to share it. Defeats chunk locality — N readers do N pointer chases instead of one chunk scan.\n- ❌ Calling `SystemAPI.GetSingleton\u003CT>` *inside* a parallel job. Singletons aren't job-safe. Capture into the job struct as a value on the main thread before scheduling.\n- ❌ A \"singleton\" component that exists on more than one entity in production data. Add a baking validator that fails the build if `query.CalculateEntityCount() != 1`.\n\n## Failure modes\n\n| Symptom | Cause |\n|---|---|\n| `InvalidOperationException: GetSingleton\u003CT> requires exactly one matching entity but found N` | Two entities now carry the component (often a duplicated Baker), or zero (missed `RequireForUpdate` or scene not loaded) |\n| Config visibly stale | Reader runs before the writer in the same group with no `[UpdateAfter]` — see `dots-update-groups` |\n| Burst-time exception inside parallel job | `SystemAPI.GetSingleton` called from inside the job — must be hoisted to `OnUpdate` and passed via job field |\n| Singleton \"resets\" every frame | Writer in OnUpdate overwriting a bake-time value — bake-time singletons should be treated immutable |\n| Singleton missing after subscene unload | Bake-time singletons live in the subscene — unloading destroys them; readers must `RequireForUpdate` or `HasSingleton`-guard |\n\n## Runtime verification (Tester Verification Contract)\n\n- **Static:** grep every `GetSingleton\u003CT>` \u002F `GetSingletonRW\u003CT>`. Each must be paired with a `RequireForUpdate\u003CT>` in the same system's `OnCreate`, OR wrapped in `HasSingleton\u003CT>` \u002F `TryGetSingleton\u003CT>`. Anything else is a latent throw.\n- **Runtime:** at frame N (post-load), assert `world.EntityManager.CreateEntityQuery(ComponentType.ReadOnly\u003CT>()).CalculateEntityCount() == 1` for every component intended as a singleton. Add as a one-shot validation system in builds.\n\n## Performance notes\n\n- `GetSingleton\u003CT>` is cheap (cached query lookup). Repeated calls in `OnUpdate` are fine but capture into a local for clarity.\n- `GetSingletonRW\u003CT>` marks the component as written and adds to the dependency graph. Don't sprinkle it where read access suffices.\n- Singletons read by jobs should be passed *by value* into the job struct. Passing a `ComponentLookup\u003CT>` for a single read is wasted indirection.\n\n## Compile \u002F editor safety\n\n- `[InternalBufferCapacity]` doesn't apply to singletons (they're scalar). Buffer-singletons are a separate consideration (often a `DynamicBuffer\u003CT>` on a known entity).\n- Singleton component types should still be `[BurstCompile]`-friendly (blittable, no managed refs) unless explicitly part of the hybrid bridge.\n\n## Entities version notes (1.4.x)\n\n- `SystemAPI.GetSingleton\u003CT>()` \u002F `GetSingletonRW\u003CT>()` \u002F `HasSingleton\u003CT>()` \u002F `TryGetSingleton\u003CT>()` — current.\n- `state.EntityManager.CreateSingleton\u003CT>()` — **does not exist**. Refuse old code that uses it. Create an entity, add the component, that's the singleton.\n- `World.GetOrCreateSingleton\u003CT>` — 0.x, gone. Use `RequireForUpdate` + `GetSingleton`.\n- For ECB systems, the canonical handle is `EndSimulationEntityCommandBufferSystem.Singleton` (nested type) — not `World.GetExistingSystemManaged\u003C...>()`.\n\n## See also\n- `dots-update-groups` — writer-before-reader ordering for mutable singletons\n- `dots-spawning-patterns` — Spawner singletons are covered there; this skill is about cross-system shared state\n- `dots-ecb-orchestration` — ECB-system singletons are the canonical example of \"read-only handle singleton\"\n","# Singleton Patterns — Senior Patterns\n\nA \"singleton\" in DOTS is a component on **exactly one entity**, accessed through a uniform API. It is not a static field, not a `World.GetOrCreate\u003CT>`, and not a service locator. Misuse is silent until the day a second entity gets the component and the system throws on `GetSingleton`.\n\n## Intent\n\nShare a single piece of state across many systems with one declared writer, one well-defined creation point, and a runtime invariant (one and only one).\n\n## Three creation pathways (pick one per singleton, document it)\n\n| Pathway | When | Mutability |\n|---|---|---|\n| **Bake-time** (Authoring + Baker writes one entity in the subscene) | Frame-stable config: game settings, level parameters, level-load seed | Immutable at runtime (treat as `readonly`) |\n| **Runtime-created** (`state.EntityManager.CreateEntity` + `AddComponent` in `OnCreate` of an owner system) | Mutable game state: current input snapshot, level-loaded flag, frame stats | One owner writes; others read |\n| **ECB-system singleton** (`EndSimulationEntityCommandBufferSystem.Singleton` etc.) | Built-in: ECB recorder handles | Read-only handle, never written by user code |\n\n## Senior pattern\n\n```csharp\n\u002F\u002F Component carries data; nothing on it forces uniqueness — the contract is enforced\n\u002F\u002F by your code paths, NOT by a type-system marker.\npublic struct LevelConfig : IComponentData\n{\n    public int   LevelIndex;\n    public float Gravity;\n    public uint  Seed;\n}\n\npublic partial struct GravitySystem : ISystem\n{\n    [BurstCompile]\n    public void OnCreate(ref SystemState state)\n    {\n        \u002F\u002F Declares \"we need this singleton\" — system idles cleanly until it exists.\n        \u002F\u002F Without this, GetSingleton\u003CLevelConfig>() throws if the singleton is missing.\n        state.RequireForUpdate\u003CLevelConfig>();\n    }\n\n    [BurstCompile]\n    public void OnUpdate(ref SystemState state)\n    {\n        \u002F\u002F Read path — safe because RequireForUpdate guarantees existence.\n        var cfg = SystemAPI.GetSingleton\u003CLevelConfig>();\n\n        \u002F\u002F Hot path: capture into job, don't call SystemAPI from inside the job.\n        new ApplyGravityJob { Gravity = cfg.Gravity, Dt = SystemAPI.Time.DeltaTime }\n            .ScheduleParallel();\n    }\n}\n\n\u002F\u002F Mutation: ONE owner system writes via GetSingletonRW. Mark single-writer in code review.\npublic partial struct LevelClockSystem : ISystem\n{\n    [BurstCompile]\n    public void OnUpdate(ref SystemState state)\n    {\n        var cfgRef = SystemAPI.GetSingletonRW\u003CLevelConfig>();\n        cfgRef.ValueRW.Seed = cfgRef.ValueRO.Seed + 1u;\n    }\n}\n```\n\n## Optional \u002F nullable singletons\n\nWhen the singleton may not exist (level not loaded yet, ECB system not available):\n\n```csharp\nif (SystemAPI.HasSingleton\u003CLevelConfig>())\n{\n    var cfg = SystemAPI.GetSingleton\u003CLevelConfig>();\n    \u002F\u002F ...\n}\n\n\u002F\u002F Or:\nif (SystemAPI.TryGetSingleton\u003CLevelConfig>(out var cfg)) { \u002F* ... *\u002F }\n```\n\nPrefer `RequireForUpdate\u003CT>` over runtime `HasSingleton` checks — it gates the whole `OnUpdate`, saves the dispatch when not present, and documents intent.\n\n## Anti-patterns\n\n- ❌ Two systems calling `GetSingletonRW\u003CT>` on the same component. Single-writer contract violation. Code review must reject — even if both writers happen to write the same value, the dependency graph becomes a race.\n- ❌ Iterating an `EntityQuery` to find \"the one entity\" instead of `SystemAPI.GetSingletonEntity\u003CT>()`. Slower and breaks if a second entity ever appears.\n- ❌ Putting hot per-frame per-entity data on a singleton just to share it. Defeats chunk locality — N readers do N pointer chases instead of one chunk scan.\n- ❌ Calling `SystemAPI.GetSingleton\u003CT>` *inside* a parallel job. Singletons aren't job-safe. Capture into the job struct as a value on the main thread before scheduling.\n- ❌ A \"singleton\" component that exists on more than one entity in production data. Add a baking validator that fails the build if `query.CalculateEntityCount() != 1`.\n\n## Failure modes\n\n| Symptom | Cause |\n|---|---|\n| `InvalidOperationException: GetSingleton\u003CT> requires exactly one matching entity but found N` | Two entities now carry the component (often a duplicated Baker), or zero (missed `RequireForUpdate` or scene not loaded) |\n| Config visibly stale | Reader runs before the writer in the same group with no `[UpdateAfter]` — see `dots-update-groups` |\n| Burst-time exception inside parallel job | `SystemAPI.GetSingleton` called from inside the job — must be hoisted to `OnUpdate` and passed via job field |\n| Singleton \"resets\" every frame | Writer in OnUpdate overwriting a bake-time value — bake-time singletons should be treated immutable |\n| Singleton missing after subscene unload | Bake-time singletons live in the subscene — unloading destroys them; readers must `RequireForUpdate` or `HasSingleton`-guard |\n\n## Runtime verification (Tester Verification Contract)\n\n- **Static:** grep every `GetSingleton\u003CT>` \u002F `GetSingletonRW\u003CT>`. Each must be paired with a `RequireForUpdate\u003CT>` in the same system's `OnCreate`, OR wrapped in `HasSingleton\u003CT>` \u002F `TryGetSingleton\u003CT>`. Anything else is a latent throw.\n- **Runtime:** at frame N (post-load), assert `world.EntityManager.CreateEntityQuery(ComponentType.ReadOnly\u003CT>()).CalculateEntityCount() == 1` for every component intended as a singleton. Add as a one-shot validation system in builds.\n\n## Performance notes\n\n- `GetSingleton\u003CT>` is cheap (cached query lookup). Repeated calls in `OnUpdate` are fine but capture into a local for clarity.\n- `GetSingletonRW\u003CT>` marks the component as written and adds to the dependency graph. Don't sprinkle it where read access suffices.\n- Singletons read by jobs should be passed *by value* into the job struct. Passing a `ComponentLookup\u003CT>` for a single read is wasted indirection.\n\n## Compile \u002F editor safety\n\n- `[InternalBufferCapacity]` doesn't apply to singletons (they're scalar). Buffer-singletons are a separate consideration (often a `DynamicBuffer\u003CT>` on a known entity).\n- Singleton component types should still be `[BurstCompile]`-friendly (blittable, no managed refs) unless explicitly part of the hybrid bridge.\n\n## Entities version notes (1.4.x)\n\n- `SystemAPI.GetSingleton\u003CT>()` \u002F `GetSingletonRW\u003CT>()` \u002F `HasSingleton\u003CT>()` \u002F `TryGetSingleton\u003CT>()` — current.\n- `state.EntityManager.CreateSingleton\u003CT>()` — **does not exist**. Refuse old code that uses it. Create an entity, add the component, that's the singleton.\n- `World.GetOrCreateSingleton\u003CT>` — 0.x, gone. Use `RequireForUpdate` + `GetSingleton`.\n- For ECB systems, the canonical handle is `EndSimulationEntityCommandBufferSystem.Singleton` (nested type) — not `World.GetExistingSystemManaged\u003C...>()`.\n\n## See also\n- `dots-update-groups` — writer-before-reader ordering for mutable singletons\n- `dots-spawning-patterns` — Spawner singletons are covered there; this skill is about cross-system shared state\n- `dots-ecb-orchestration` — ECB-system singletons are the canonical example of \"read-only handle singleton\"\n",{"name":5,"description":7},"main","fe4746b9f07e6c7c2b6d3932002183af9b9f6fa2","workspace\u002Fdots-program\u002Fscratch\u002Fwave-2-orchestrator-drafts\u002Fdots-singleton-patterns",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":58,"prompt":68,"zipAvailable":69},[59,62,65],{"tool":60,"command":61},"npx","npx skills add dyCuong03\u002Funity-agent-team --skill dots-singleton-patterns",{"tool":63,"command":64},"bunx","bunx skills add dyCuong03\u002Funity-agent-team --skill dots-singleton-patterns",{"tool":66,"command":67},"pnpm","pnpm dlx skills add dyCuong03\u002Funity-agent-team --skill dots-singleton-patterns","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FdyCuong03\u002Funity-agent-team\u002Fblob\u002Fmain\u002Fworkspace\u002Fdots-program\u002Fscratch\u002Fwave-2-orchestrator-drafts\u002Fdots-singleton-patterns\u002FSKILL.md",true,[],[72,94,114,134,155,188],{"skillNo":73,"name":74,"nameZh":6,"description":75,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":76,"categories":77,"keywords":78,"publishedAt":44},"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",[],[79,80,81,82,83,40,84,85,38,86,87,88,89,90,91,92,30,93],"update","dots update groups","boundary","simulation","how","choose","work","never","peer","deterministic","how to","coupling","ecs","bugs","value",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":44},"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",[],[26,101,102,103,81,40,104,39,38,105,34,106,107,31,108,109,110,111,112,113],"transform","dots transform patterns","components","mount","cost","systems","input","matrix","socket","at","child","custom","hierarchy",{"skillNo":115,"name":116,"nameZh":6,"description":117,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":118,"categories":119,"keywords":120,"publishedAt":44},"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",[],[121,122,123,124,103,42,81,125,126,85,127,128,38,34,129,130,107,131,132,133],"bridge","hybrid","dots hybrid bridge","mesh","assets","Rules","read","view","trigger","unity","material","for","managed",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":140,"publishedAt":44},"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",[],[141,142,91,143,144,103,145,146,147,39,85,148,149,26,150,151,107,152,153,154],"event driven","driven","event","dots event driven ecs","change","ui","network","command","anti-patterns","pattern","structural","events","static","request",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":172,"publishedAt":44},"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",[161,166,169],{"categoryNo":162,"categoryName":163,"taxonomyType":164,"taxonomyTypeDesc":165},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":167,"categoryName":168,"taxonomyType":164,"taxonomyTypeDesc":165},"01JBSEEDCAT000000000000008","测试与质量",{"categoryNo":170,"categoryName":171,"taxonomyType":164,"taxonomyTypeDesc":165},"01JBSEEDCAT000000000000023","Skill与智能体开发",[173,174,175,176,177,178,179,180,181,182,183,184,185,186,130,187,132],"valid skill","valid","code review","testing","review","test","routing","code","validation","projects","fixture skill","task","fixture","basic","complete",{"skillNo":189,"name":190,"nameZh":6,"description":191,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":192,"categories":193,"keywords":194,"publishedAt":44},"01M6KH48R1VP1FPD07Y8RHD1QM","unsafe_commands","Skill fixture containing unsafe shell commands for security testing. Should be flagged by the validator.","https:\u002F\u002Fgithub.com\u002FdyCuong03\u002Funity-agent-team\u002Fblob\u002Fmain\u002Ftests\u002Ffixtures\u002Funsafe_commands\u002FSKILL.md",[],[195,196,197,176,198,199,185,200,201,132,202],"commands","unsafe","unsafe commands","security","shell","Security Testing","validator","skill fixture"]