Update to Unity Essentials

{
  "description": "Implement, extend, or integrate a feature in an existing Unity project while respecting its architecture, coding conventions, scene structure, packages, networking model, and validation workflow. Use when the user asks to add gameplay mechanics, UI behavior, systems, editor tools, integrations, ScriptableObjects, shaders, VFX, networking functionality, save systems, input behavior, XR interactions, audio, animation, AI, or other concrete Unity features.",
  "included_files": [
    {
      "relative_path": "FILE-INVENTORY.md",
      "size_in_bytes": 1277
    },
    {
      "relative_path": "README.md",
      "size_in_bytes": 899
    },
    {
      "relative_path": "foundations/architecture-and-clean-code.md",
      "size_in_bytes": 6170
    },
    {
      "relative_path": "foundations/performance-basics.md",
      "size_in_bytes": 1776
    },
    {
      "relative_path": "foundations/serialization-safety.md",
      "size_in_bytes": 2532
    },
    {
      "relative_path": "foundations/testing.md",
      "size_in_bytes": 1697
    },
    {
      "relative_path": "foundations/unity-lifecycle.md",
      "size_in_bytes": 2946
    },
    {
      "relative_path": "frameworks/input/input-system.md",
      "size_in_bytes": 491
    },
    {
      "relative_path": "frameworks/input/legacy-input.md",
      "size_in_bytes": 369
    },
    {
      "relative_path": "frameworks/networking/fishnet.md",
      "size_in_bytes": 526
    },
    {
      "relative_path": "frameworks/networking/fusion.md",
      "size_in_bytes": 818
    },
    {
      "relative_path": "frameworks/networking/mirror.md",
      "size_in_bytes": 560
    },
    {
      "relative_path": "frameworks/networking/netcode-for-gameobjects.md",
      "size_in_bytes": 667
    },
    {
      "relative_path": "frameworks/rendering/built-in.md",
      "size_in_bytes": 352
    },
    {
      "relative_path": "frameworks/rendering/hdrp.md",
      "size_in_bytes": 440
    },
    {
      "relative_path": "frameworks/rendering/urp.md",
      "size_in_bytes": 446
    },
    {
      "relative_path": "frameworks/ui/ugui.md",
      "size_in_bytes": 460
    },
    {
      "relative_path": "frameworks/ui/ui-toolkit.md",
      "size_in_bytes": 485
    },
    {
      "relative_path": "frameworks/xr/openxr.md",
      "size_in_bytes": 452
    },
    {
      "relative_path": "frameworks/xr/xr-interaction-toolkit.md",
      "size_in_bytes": 566
    },
    {
      "relative_path": "references/capability-requirements.md",
      "size_in_bytes": 1519
    },
    {
      "relative_path": "references/implementation-plan-template.md",
      "size_in_bytes": 1085
    },
    {
      "relative_path": "references/unity-change-safety.md",
      "size_in_bytes": 871
    },
    {
      "relative_path": "references/validation-strategy.md",
      "size_in_bytes": 1246
    },
    {
      "relative_path": "specializations/ai-navigation.md",
      "size_in_bytes": 889
    },
    {
      "relative_path": "specializations/animation.md",
      "size_in_bytes": 896
    },
    {
      "relative_path": "specializations/audio.md",
      "size_in_bytes": 785
    },
    {
      "relative_path": "specializations/editor-tools.md",
      "size_in_bytes": 965
    },
    {
      "relative_path": "specializations/gameplay.md",
      "size_in_bytes": 1326
    },
    {
      "relative_path": "specializations/input.md",
      "size_in_bytes": 954
    },
    {
      "relative_path": "specializations/multiplayer.md",
      "size_in_bytes": 1264
    },
    {
      "relative_path": "specializations/performance.md",
      "size_in_bytes": 844
    },
    {
      "relative_path": "specializations/save-systems.md",
      "size_in_bytes": 956
    },
    {
      "relative_path": "specializations/shaders.md",
      "size_in_bytes": 970
    },
    {
      "relative_path": "specializations/ui.md",
      "size_in_bytes": 950
    },
    {
      "relative_path": "specializations/vfx.md",
      "size_in_bytes": 914
    },
    {
      "relative_path": "specializations/xr.md",
      "size_in_bytes": 992
    }
  ],
  "name": "unity-feature-implementation",
  "skill_md_contents": "---\nname: unity-feature-implementation\ndescription: Implement, extend, or integrate a feature in an existing Unity project while respecting its architecture, coding conventions, scene structure, packages, networking model, and validation workflow. Use when the user asks to add gameplay mechanics, UI behavior, systems, editor tools, integrations, ScriptableObjects, shaders, VFX, networking functionality, save systems, input behavior, XR interactions, audio, animation, AI, or other concrete Unity features.\n---\n\n# Unity Feature Implementation\n\nImplement Unity features as coherent additions to the existing project.\n\nDo not treat a feature request as an isolated code-generation task. Understand\nhow the project currently solves related problems, identify the correct\nextension points, implement the smallest complete solution, and validate it\nusing the strongest available evidence.\n\n## Surface Limits\n\nIf the current surface is Chat mode without an attached workspace, repository files, or local filesystem access, do not claim that you can implement or validate changes in the user's Unity project. Explain that Unity Essentials can help reason from pasted code or screenshots, but real implementation requires Codex with the Unity project folder open.\n\nIf Codex has a workspace or local files available, inspect the project before editing and report validation honestly.\n\n## Primary outcome\n\nDeliver a working implementation that:\n\n- follows the project's existing architecture\n- respects current coding conventions\n- integrates with existing systems\n- avoids unnecessary dependencies\n- minimizes scene and prefab changes\n- compiles without new errors\n- includes appropriate tests or validation\n- documents assumptions and remaining setup\n\n## Relationship with project onboarding\n\nBefore implementing a substantial feature, look for an existing project context\ndocument such as:\n\n- `Docs/AI/UnityProjectContext.md`\n- `Docs/UnityProjectContext.md`\n- project-specific AI or architecture documentation\n\nIf no reliable context exists and the project is unfamiliar, use the\n`unity-project-onboarding` workflow first.\n\nDo not repeat a complete onboarding when the necessary project context is\nalready current and supported by repository evidence.\n\n## Knowledge routing\n\nBefore planning or editing, determine which internal guidance applies.\n\nThe skill contains three categories:\n\n- `foundations/`: cross-cutting engineering rules\n- `specializations/`: rules for a particular feature area\n- `frameworks/`: rules for a concrete Unity package or technology\n\nRead only the files that materially apply.\n\n### Mandatory foundations\n\nFor every non-trivial runtime feature, read:\n\n- `foundations/architecture-and-clean-code.md`\n- `foundations/unity-lifecycle.md`\n- `foundations/testing.md`\n\nRead `foundations/serialization-safety.md` when the change affects:\n\n- serialized fields\n- scenes\n- prefabs\n- ScriptableObjects\n- materials\n- animation controllers\n- project settings\n- input action assets\n\nRead `foundations/performance-basics.md` when the feature affects:\n\n- frequently executed runtime code\n- Update, FixedUpdate, or LateUpdate\n- spawning\n- collections\n- networking\n- rendering\n- UI refreshes\n- asset loading\n\n### Specialization routing\n\nA task may use more than one specialization.\n\n| Area | File |\n|---|---|\n| Gameplay mechanics | `specializations/gameplay.md` |\n| Player input | `specializations/input.md` |\n| UI and HUD | `specializations/ui.md` |\n| Multiplayer | `specializations/multiplayer.md` |\n| Save data | `specializations/save-systems.md` |\n| Shaders and rendering behavior | `specializations/shaders.md` |\n| Particle System and VFX Graph | `specializations/vfx.md` |\n| Editor extensions | `specializations/editor-tools.md` |\n| XR and VR | `specializations/xr.md` |\n| Audio | `specializations/audio.md` |\n| Animation systems | `specializations/animation.md` |\n| Navigation and gameplay AI | `specializations/ai-navigation.md` |\n| Explicit optimization work | `specializations/performance.md` |\n\n### Framework routing\n\nRead a framework guide only when the project actively uses that framework.\n\nDo not select a framework merely because its package is installed.\n\nConfirm usage through:\n\n- project context\n- package configuration\n- assembly references\n- first-party code\n- scenes or prefabs\n- project documentation\n\n### Resolution priority\n\nWhen guidance conflicts, use this priority:\n\n1. Explicit user requirements\n2. Repository instructions and project architecture\n3. Data integrity and safety requirements\n4. Framework-specific guidance\n5. Feature specialization guidance\n6. Foundation guidance\n7. Generic Unity conventions\n\nExisting project architecture should normally be extended rather than replaced.\n\n## Proportional architecture\n\nThe architectural complexity of the solution must be proportional to:\n\n- feature complexity\n- number of consumers\n- expected variation\n- lifetime of the system\n- project size\n- testing requirements\n- networking or persistence requirements\n\nDo not introduce an abstraction solely because a design principle can be\napplied.\n\nPrefer the simplest design that preserves clear ownership, cohesion,\ntestability, and safe future change.\n\n## Feature workflow\n\n1. Interpret the request as a concrete feature contract.\n2. Read project context and relevant repository instructions.\n3. Route to the required foundations, specializations, and frameworks.\n4. Locate the correct integration points.\n5. Assess risk.\n6. Create a focused implementation plan.\n7. Implement incrementally.\n8. Compile and inspect Console output.\n9. Run relevant tests.\n10. Validate runtime behavior where possible.\n11. Review the final diff.\n12. Report completed work, validation, setup, and limitations.\n\n## Feature contract\n\nIdentify:\n\n- desired player or developer behavior\n- feature entry point\n- expected output or effect\n- affected systems\n- supported platforms\n- multiplayer implications\n- persistence implications\n- UI implications\n- performance expectations\n- failure and edge cases\n- explicit constraints\n- acceptance criteria\n\nDo not silently broaden the scope.\n\nWhen requirements are incomplete, infer the smallest conventional behavior that\nfits the existing project.\n\nAsk a question only when an unresolved choice would substantially change the\npublic API, architecture, data format, network behavior, or visible result.\nOtherwise, make a conservative decision and document it.\n\n## Integration analysis\n\nBefore editing, answer:\n\n1. Which existing component owns this responsibility?\n2. Which assembly should contain the new code?\n3. Is there already an extension point?\n4. Does the project favor composition, inheritance, events, or services here?\n5. Is configuration stored in prefabs, ScriptableObjects, settings, or code?\n6. Does this behavior require scene or prefab wiring?\n7. Who owns state authority in multiplayer?\n8. What behavior must remain unchanged?\n9. What is the smallest coherent file set?\n10. How will the feature be verified?\n\nDo not create a new manager, singleton, service locator, event bus, or framework\nwhen an existing system already covers the responsibility.\n\n## Risk classification\n\n### Low risk\n\n- isolated plain C# logic\n- utility methods\n- non-breaking configuration additions\n- EditMode tests\n- localized editor-only tooling\n\n### Medium risk\n\n- modifying runtime MonoBehaviours\n- adding input handling\n- changing ScriptableObject schemas\n- adding runtime UI\n- extending state machines\n- modifying a prefab with limited usage\n\n### High risk\n\n- editing shared scenes or base prefabs\n- changing public APIs used across assemblies\n- modifying network authority\n- changing serialization layouts\n- changing addressable keys\n- altering render-pipeline settings\n- changing initialization order\n- modifying Build Settings\n- changing persistent save formats\n\nFor medium- and high-risk changes, identify affected assets, rollback strategy,\ncompatibility concerns, and required validation.\n\n## Implementation rules\n\n- Extend existing systems before creating parallel systems.\n- Prefer the smallest coherent implementation.\n- Avoid unrelated refactors.\n- Preserve public APIs unless change is necessary.\n- Search all usages before changing public members.\n- Preserve serialized field names where possible.\n- Use `FormerlySerializedAs` when renaming serialized fields.\n- Follow existing async, DI, event, and state-management patterns.\n- Keep Unity lifecycle methods understandable.\n- Keep mutable state ownership clear.\n- Avoid hidden dependencies.\n- Do not add packages without explicit need and authorization.\n- Do not edit generated directories or IDE artifacts.\n- Do not claim validation that did not occur.\n\n## Unity tooling\n\nUse conceptual capabilities rather than hardcoded MCP tool names.\n\nRead capabilities may include:\n\n- `unity.connection.status`\n- `unity.console.read`\n- `unity.scene.inspect`\n- `unity.buildsettings.read`\n- `unity.gameobject.inspect`\n- `unity.asset.search`\n- `unity.tests.list`\n- `unity.playmode.read`\n\nMutation capabilities may include:\n\n- `unity.script.create`\n- `unity.script.modify`\n- `unity.asset.modify`\n- `unity.gameobject.modify`\n- `unity.scene.modify`\n- `unity.playmode.set`\n- `unity.tests.run`\n\nBefore invoking a mutating tool:\n\n1. Confirm it targets the active Unity project.\n2. Understand its side effects.\n3. Prefer the most narrowly scoped operation.\n4. Preserve existing serialized data.\n5. Re-read affected state after mutation.\n6. Check Console output after imports or recompilation.\n\n## Definition of done\n\nA feature is complete when:\n\n- requested behavior is clearly understood\n- correct integration points were identified\n- implementation follows project architecture and conventions\n- necessary code and safe asset changes are complete\n- Unity or the strongest available fallback compiles\n- no new unresolved errors were introduced\n- relevant tests pass or limitations are reported\n- runtime behavior was validated at an appropriate level\n- serialized references and setup requirements are accounted for\n- final diff contains no unrelated changes\n- assumptions and risks are documented\n- remaining manual steps are explicit\n- documentation is updated when necessary\n\n## Final response\n\nReturn:\n\n### Implemented\n\nSummarize completed behavior.\n\n### Changed files\n\nList important created and modified files with purpose.\n\n### Validation\n\nState exactly what was validated.\n\n### Setup\n\nList required Inspector, scene, prefab, input, package, or build setup.\n\n### Assumptions and limitations\n\nRecord important assumptions and remaining risks.\n"
}