Update to Unity Essentials

{
  "description": "Audit the technical health of an existing Unity project without making changes by default. Use when the user asks for a project review, technical audit, architecture review, performance scan, package review, build readiness check, maintainability assessment, risk analysis, or general Unity project health report. Inspect evidence across code, assemblies, scenes, prefabs, packages, settings, tests, performance-sensitive paths, networking, rendering, persistence, and build configuration. Produce prioritized findings with severity, confidence, evidence, impact, and recommended next actions.",
  "included_files": [
    {
      "relative_path": "FILE-INVENTORY.md",
      "size_in_bytes": 1356
    },
    {
      "relative_path": "README.md",
      "size_in_bytes": 799
    },
    {
      "relative_path": "checklists/architecture-and-maintainability.md",
      "size_in_bytes": 586
    },
    {
      "relative_path": "checklists/assemblies-and-dependencies.md",
      "size_in_bytes": 434
    },
    {
      "relative_path": "checklists/builds-platforms-ci.md",
      "size_in_bytes": 440
    },
    {
      "relative_path": "checklists/code-quality.md",
      "size_in_bytes": 583
    },
    {
      "relative_path": "checklists/editor-tooling-and-imports.md",
      "size_in_bytes": 425
    },
    {
      "relative_path": "checklists/input-and-device-support.md",
      "size_in_bytes": 386
    },
    {
      "relative_path": "checklists/lifecycle-and-initialization.md",
      "size_in_bytes": 471
    },
    {
      "relative_path": "checklists/memory-and-assets.md",
      "size_in_bytes": 457
    },
    {
      "relative_path": "checklists/multiplayer.md",
      "size_in_bytes": 439
    },
    {
      "relative_path": "checklists/packages-and-compatibility.md",
      "size_in_bytes": 443
    },
    {
      "relative_path": "checklists/performance.md",
      "size_in_bytes": 486
    },
    {
      "relative_path": "checklists/project-hygiene.md",
      "size_in_bytes": 436
    },
    {
      "relative_path": "checklists/rendering-and-vfx.md",
      "size_in_bytes": 441
    },
    {
      "relative_path": "checklists/save-and-persistence.md",
      "size_in_bytes": 369
    },
    {
      "relative_path": "checklists/scenes-prefabs-serialization.md",
      "size_in_bytes": 443
    },
    {
      "relative_path": "checklists/security-and-secrets.md",
      "size_in_bytes": 366
    },
    {
      "relative_path": "checklists/testing-and-validation.md",
      "size_in_bytes": 391
    },
    {
      "relative_path": "checklists/ui-localization-accessibility.md",
      "size_in_bytes": 504
    },
    {
      "relative_path": "foundations/evidence-and-confidence.md",
      "size_in_bytes": 1085
    },
    {
      "relative_path": "foundations/read-only-audit-safety.md",
      "size_in_bytes": 991
    },
    {
      "relative_path": "foundations/reporting-quality.md",
      "size_in_bytes": 815
    },
    {
      "relative_path": "foundations/severity-and-prioritization.md",
      "size_in_bytes": 956
    },
    {
      "relative_path": "frameworks/networking/fishnet.md",
      "size_in_bytes": 330
    },
    {
      "relative_path": "frameworks/networking/fusion.md",
      "size_in_bytes": 480
    },
    {
      "relative_path": "frameworks/networking/mirror.md",
      "size_in_bytes": 339
    },
    {
      "relative_path": "frameworks/networking/netcode-for-gameobjects.md",
      "size_in_bytes": 427
    },
    {
      "relative_path": "frameworks/rendering/hdrp.md",
      "size_in_bytes": 346
    },
    {
      "relative_path": "frameworks/rendering/urp.md",
      "size_in_bytes": 367
    },
    {
      "relative_path": "references/audit-plan-template.md",
      "size_in_bytes": 620
    },
    {
      "relative_path": "references/capability-requirements.md",
      "size_in_bytes": 937
    },
    {
      "relative_path": "references/finding-template.md",
      "size_in_bytes": 458
    },
    {
      "relative_path": "references/health-report-template.md",
      "size_in_bytes": 631
    },
    {
      "relative_path": "references/health-scoring.md",
      "size_in_bytes": 747
    }
  ],
  "name": "unity-project-health-check",
  "skill_md_contents": "---\nname: unity-project-health-check\ndescription: Audit the technical health of an existing Unity project without making changes by default. Use when the user asks for a project review, technical audit, architecture review, performance scan, package review, build readiness check, maintainability assessment, risk analysis, or general Unity project health report. Inspect evidence across code, assemblies, scenes, prefabs, packages, settings, tests, performance-sensitive paths, networking, rendering, persistence, and build configuration. Produce prioritized findings with severity, confidence, evidence, impact, and recommended next actions.\n---\n\n# Unity Project Health Check\n\nAssess the technical health of a Unity project using evidence from the\nrepository and, when available, the connected Unity Editor.\n\nThe default mode is read-only.\n\nDo not automatically fix findings unless the user explicitly asks for\nremediation.\n\n## Surface Limits\n\nIf the current surface is Chat mode without an attached workspace, repository files, or local filesystem access, do not present a project health report as if the project was audited. Explain that Unity Essentials can provide an audit checklist or review pasted evidence, but a real health check requires Codex with the Unity project folder open.\n\nIf Codex has a workspace or local files available, keep the audit evidence-based and read-only by default.\n\n## Primary outcome\n\nProduce a concise, prioritized report that answers:\n\n- What is healthy?\n- What is risky?\n- What is broken or likely to break?\n- What should be fixed first?\n- Which findings are confirmed, likely, or unknown?\n- Which checks could not be completed?\n\n## Relationship with onboarding\n\nLook for an existing context document:\n\n- `Docs/AI/UnityProjectContext.md`\n- `Docs/UnityProjectContext.md`\n- architecture documentation\n- repository instructions\n\nIf no reliable project context exists, use the\n`unity-project-onboarding` workflow first or perform the minimum equivalent\ninspection needed for the audit.\n\nDo not duplicate complete onboarding findings in the health report.\n\n## Default behavior\n\nThe health check is read-only unless explicitly requested otherwise.\n\nDo not:\n\n- modify code\n- edit scenes or prefabs\n- install or update packages\n- change Project Settings\n- enter Play Mode without a validation need\n- trigger builds without a clear reason\n- clear the Console\n- rewrite documentation\n- delete generated folders\n\n## Knowledge routing\n\nThe skill contains:\n\n- `foundations/`: audit principles and reporting rules\n- `checklists/`: health domains\n- `frameworks/`: framework-specific review criteria\n- `references/`: templates, scoring, and capability guidance\n\nRead only the areas relevant to the requested scope.\n\n### Mandatory foundations\n\nAlways read:\n\n- `foundations/evidence-and-confidence.md`\n- `foundations/severity-and-prioritization.md`\n- `foundations/read-only-audit-safety.md`\n- `foundations/reporting-quality.md`\n\n### Checklist routing\n\n| Audit area | File |\n|---|---|\n| Architecture and coupling | `checklists/architecture-and-maintainability.md` |\n| Code quality and C# risks | `checklists/code-quality.md` |\n| Unity lifecycle and initialization | `checklists/lifecycle-and-initialization.md` |\n| Assemblies and dependencies | `checklists/assemblies-and-dependencies.md` |\n| Packages and compatibility | `checklists/packages-and-compatibility.md` |\n| Scenes, prefabs, and serialization | `checklists/scenes-prefabs-serialization.md` |\n| Performance and allocations | `checklists/performance.md` |\n| Memory and asset loading | `checklists/memory-and-assets.md` |\n| Rendering, shaders, and VFX | `checklists/rendering-and-vfx.md` |\n| Multiplayer and networking | `checklists/multiplayer.md` |\n| Save data and persistence | `checklists/save-and-persistence.md` |\n| UI, localization, and accessibility | `checklists/ui-localization-accessibility.md` |\n| Input and device support | `checklists/input-and-device-support.md` |\n| Tests and validation | `checklists/testing-and-validation.md` |\n| Builds, platforms, and CI | `checklists/builds-platforms-ci.md` |\n| Security and secrets | `checklists/security-and-secrets.md` |\n| Editor tooling and imports | `checklists/editor-tooling-and-imports.md` |\n| Project hygiene and version control | `checklists/project-hygiene.md` |\n\n### Framework routing\n\nRead framework guidance only when active use is confirmed.\n\n| Framework | File |\n|---|---|\n| Photon Fusion | `frameworks/networking/fusion.md` |\n| Netcode for GameObjects | `frameworks/networking/netcode-for-gameobjects.md` |\n| Mirror | `frameworks/networking/mirror.md` |\n| FishNet | `frameworks/networking/fishnet.md` |\n| URP | `frameworks/rendering/urp.md` |\n| HDRP | `frameworks/rendering/hdrp.md` |\n\n## Audit modes\n\n### Focused\n\nUse when the user asks about one area, such as performance or architecture.\n\nInspect only the relevant domains and immediate dependencies.\n\n### Standard\n\nUse for a general project health review.\n\nInspect all high-value domains, but sample large repositories rather than\nreading every file.\n\n### Release readiness\n\nUse before a milestone, demo, submission, or launch.\n\nPrioritize:\n\n- compilation\n- Console\n- tests\n- scenes\n- builds\n- packages\n- missing references\n- platform issues\n- persistence\n- severe performance risks\n\n### Deep audit\n\nUse only when explicitly requested or clearly justified.\n\nMay include:\n\n- broad code sampling\n- full assembly analysis\n- package compatibility review\n- profiler capture\n- build validation\n- multi-peer networking review\n- target-device validation\n\n## Core principles\n\n1. Evidence before conclusions.\n2. Read-only by default.\n3. Separate confirmed defects from code smells.\n4. Prioritize impact, not stylistic preference.\n5. Respect existing architecture.\n6. Do not recommend rewrites without strong justification.\n7. Prefer actionable findings.\n8. Avoid generic Unity advice.\n9. Do not count generated or vendor code as first-party debt.\n10. Report audit limitations.\n11. Do not claim runtime, build, or platform validation that did not occur.\n12. Keep the report proportionate to the project and request.\n\n## Phase 1: Define audit scope\n\nDetermine:\n\n- focused, standard, release readiness, or deep audit\n- target platform\n- Unity version\n- project size\n- active frameworks\n- performance requirements\n- multiplayer requirements\n- release stage\n- known concerns\n- whether Editor tools are available\n\nIf the user did not specify scope, use a standard read-only audit.\n\n## Phase 2: Establish baseline\n\nInspect:\n\n- project context\n- Unity version\n- package manifest and lock file\n- repository instructions\n- current Console messages\n- current test status\n- build scene configuration\n- first-party assemblies\n- top-level first-party directories\n- recent relevant changes when useful\n\nDistinguish pre-existing known issues from newly discovered findings.\n\n## Phase 3: Separate first-party and vendor code\n\nIdentify likely:\n\n- first-party code\n- embedded packages\n- third-party packages\n- generated source\n- imported Asset Store content\n- examples and samples\n- test fixtures\n- build artifacts\n\nDo not report vendor implementation details as project-owned issues unless the\nproject integration creates the risk.\n\n## Phase 4: Route to audit domains\n\nSelect the required checklists.\n\nFor a standard audit, normally include:\n\n- architecture\n- code quality\n- lifecycle\n- assemblies\n- packages\n- scenes and serialization\n- performance\n- memory and assets\n- tests\n- builds\n- project hygiene\n\nInclude networking, rendering, UI, input, persistence, or editor tooling when\nthe project actively uses them.\n\n## Phase 5: Gather evidence\n\nUse:\n\n- configuration files\n- package metadata\n- assembly definitions\n- representative first-party code\n- scene and prefab inspection\n- Console messages\n- test results\n- profiler data\n- build logs\n- Git metadata\n- project documentation\n\nSample intelligently.\n\nDo not read every file unless the audit requires it.\n\n## Phase 6: Record findings\n\nUse `references/finding-template.md`.\n\nEach finding should contain:\n\n- title\n- domain\n- severity\n- confidence\n- evidence\n- impact\n- recommendation\n- remediation size\n- validation needed\n- affected paths\n\nDo not report a style preference as a defect.\n\n## Phase 7: Deduplicate and group\n\nCombine findings that share one root cause.\n\nExample:\n\nDo not report ten separate missing-reference symptoms when they all result from\none broken prefab base.\n\nGroup findings by:\n\n- architecture\n- correctness\n- performance\n- maintainability\n- release risk\n- data integrity\n- platform compatibility\n\n## Phase 8: Prioritize\n\nUse `references/health-scoring.md`.\n\nPrioritize based on:\n\n- user impact\n- crash or data-loss risk\n- release-blocking potential\n- frequency\n- scope\n- recovery difficulty\n- confidence\n- remediation cost\n\nDo not prioritize a low-impact clean-code issue above a build failure or save\ncorruption risk.\n\n## Phase 9: Identify healthy areas\n\nReport meaningful positive findings.\n\nExamples:\n\n- clear assembly boundaries\n- reliable automated tests\n- no new Console errors\n- consistent serialization practices\n- strong package pinning\n- clean networking authority model\n- controlled asset loading\n\nDo not add empty praise.\n\n## Phase 10: Recommend next actions\n\nProvide an ordered action plan.\n\nEach action should state:\n\n- expected benefit\n- affected finding IDs\n- likely effort\n- required validation\n- whether it can be handled by another plugin skill\n\nRecommended routing:\n\n- feature changes → `unity-feature-implementation`\n- root-cause investigation → `unity-bug-investigation`\n- final verification → `unity-build-validation`\n\n## Phase 11: Optional baseline artifact\n\nWhen useful, create or update:\n\n`Docs/AI/UnityProjectHealth.md`\n\nUse `references/health-report-template.md`.\n\nDo not create a persistent report when the user requested only a quick review.\n\nWhen updating an existing report:\n\n- preserve manually authored notes\n- update stale findings\n- close resolved findings\n- keep stable finding IDs\n- record analyzed commit and date\n\n## Severity definitions\n\n### Critical\n\nLikely to cause:\n\n- data loss\n- security exposure\n- consistent crash\n- broken production build\n- severe multiplayer integrity failure\n- project corruption\n\n### High\n\nLikely to cause:\n\n- major feature failure\n- frequent runtime errors\n- serious release risk\n- major platform incompatibility\n- severe performance degradation\n- save migration failure\n\n### Medium\n\nMeaningful maintainability, correctness, performance, or workflow risk.\n\n### Low\n\nLimited impact, localized debt, or preventive improvement.\n\n### Informational\n\nUseful observation with no immediate corrective need.\n\n## Confidence definitions\n\n### Confirmed\n\nDirectly demonstrated through configuration, code, Editor state, tests,\nprofiling, build output, or reproducible behavior.\n\n### Likely\n\nSupported by several consistent signals but not directly reproduced.\n\n### Possible\n\nPlausible and worth checking, but evidence is incomplete.\n\nDo not assign high severity with weak confidence without clearly explaining the\nuncertainty.\n\n## Definition of done\n\nThe health check is complete when:\n\n- scope is explicit\n- baseline is recorded\n- first-party and vendor code are separated\n- relevant domains were inspected\n- findings contain evidence\n- severity and confidence are assigned\n- duplicates are grouped\n- healthy areas are identified\n- limitations are explicit\n- next actions are prioritized\n- no unintended project changes were made\n- persistent report is created only when appropriate\n\n## Final response\n\nReturn:\n\n### Overall health\n\nA concise assessment and major theme.\n\n### Highest-priority findings\n\nList only the most important findings with severity and confidence.\n\n### Healthy areas\n\nMention meaningful strengths.\n\n### Recommended order\n\nProvide the most useful remediation sequence.\n\n### Audit coverage\n\nState what was and was not checked.\n\n### Report path\n\nInclude the persistent report path when created.\n"
}