Unity HybridCLR Skills

Editor-side automation for HybridCLR — the zero-cost native C# hot-update solution for IL2CPP. Covers settings CRUD, installation probing, hot-update assembly compilation, the prebuild generation pipeline, and artifact staging for a YooAsset bundle build.

This module holds zero direct references to the package. Every call resolves through reflection against the HybridCLR.Editor assembly, so the UnitySkills Editor assembly compiles identically whether or not HybridCLR is installed — there is no scripting define to set and no recompile needed after installing.

Requires: com.code-philosophy.hybridclr (API anchored to 8.12.0), IL2CPP scripting backend, Unity 2019.4+ (2022.3+ recommended). Companion modules: yooasset for shipping the compiled DLLs as bundles, yooasset-design for the runtime loading contract, asmdef for assembly-boundary design.

Guardrails

Operating Mode (v1.9 three-tier):

• Approval (default): the seven read-only skills — hybridclr_status, hybridclr_install_status, hybridclr_get_paths, hybridclr_settings_get, hybridclr_validate_setup, hybridclr_get_hotupdate_dlls, hybridclr_aot_generic_refs — are SemiAuto and run directly. hybridclr_settings_set and hybridclr_copy_hotupdate_dlls are FullAuto: on MODE_RESTRICTED, run the grant protocol.
• Auto-forbidden (NeverInSemi, RiskLevel="high"): hybridclr_compile_dlls, hybridclr_generate_all, hybridclr_generate_step. Reachable only under Bypass mode or via a user-managed Allowlist entry; the grant flow returns MODE_FORBIDDEN. This is deliberate — all three block the Editor main thread for minutes.
• When the package is missing, every skill except hybridclr_status returns a MISSING_PACKAGE error with install instructions. When the package is present but a reflected member cannot be resolved (version drift), the skill returns MISSING_PACKAGE naming the exact member instead of throwing.

DO NOT (common hallucinations):

• hybridclr_install / hybridclr_init — do NOT exist. Installing il2cpp_plus clones two git repos and copies the entire editor il2cpp tree; it is a multi-minute network operation with no cancellation and is intentionally not a skill. Run it from HybridCLR/Installer... in the Editor, or via unity-cli (see Limitations). hybridclr_install_status only reports the state.
• hybridclr_build_player — NOT in this module. Building the player is build_player (Project module) or unity-cli. HybridCLR hooks the build via its own IPreprocessBuildWithReport processors; nothing extra is needed from this module.
• hybridclr_load_metadata / hybridclr_load_assembly — runtime APIs (HybridCLR.RuntimeApi.LoadMetadataForAOTAssembly, System.Reflection.Assembly.Load) belong in game code, not the Editor REST surface. Write them yourself.
• Do NOT call hybridclr_generate_all before every bundle rebuild — see the workflow section below. It is a pre-player-build step, not a per-hot-update step.
• Do NOT pass extension=".dll" to hybridclr_copy_hotupdate_dlls. Unity would treat the staged files as managed plugins and try to load them into the Editor domain; the skill rejects it.

Routing:

• HybridCLR settings, install probing, DLL compilation, generation pipeline, artifact staging → this module.
• Packing the staged DLLs into bundles, collector configuration, build reports → yooasset.
• Runtime hot-update loading code (YooAssets.LoadAssetAsync → Assembly.Load → RuntimeApi.LoadMetadataForAOTAssembly) → write it yourself using yooasset-design.
• Deciding which assemblies belong on the hot-update side → asmdef.
• Actual player build → build_player or unity-cli.

Skills

Environment (3)

Settings (2)

Diagnostics (1)

Compile & generate (3) — blocking, high risk

Artifacts (3)

HybridCLR × YooAsset workflow

The two modules split cleanly: HybridCLR produces DLLs, YooAsset ships them. The staging step in between is hybridclr_copy_hotupdate_dlls, which renames .dll → .bytes so Unity imports them as TextAsset (a bare .dll under Assets/ would be treated as a managed plugin).

One-time setup (per project, and again after any AOT-side code change):

u.call_skill("hybridclr_settings_set",
    enable=True,
    hotUpdateAssemblyDefinitions=["Assets/HotUpdate/HotUpdate.asmdef"])
u.call_skill("hybridclr_validate_setup")     # fix every `errors` entry before continuing
u.call_skill("hybridclr_generate_all")       # minutes; domain reload follows
refs = u.call_skill("hybridclr_aot_generic_refs")
u.call_skill("hybridclr_settings_set", patchAOTAssemblies=refs["patchedAOTAssemblyList"])
# then build the player normally (build_player / unity-cli)

Iterative hot-update loop (every time hot-update C# changes — no generate_all, no player rebuild):

# 1. edit hot-update C# (script_* skills) — must live in a hotUpdateAssemblyDefinitions asmdef
# 2. compile
u.call_skill("hybridclr_compile_dlls", buildTarget="Android")
u.call_skill("hybridclr_get_hotupdate_dlls", buildTarget="Android")   # verify `missing` is empty

# 3. stage into the YooAsset collector directory
u.call_skill("hybridclr_copy_hotupdate_dlls",
    destination="Assets/HotUpdateDlls",
    buildTarget="Android",
    extension=".bytes",
    includeAotAssemblies=True,      # ships the stripped AOT metadata DLLs too
    clearDestination=True)

# 4. pack (yooasset module) — the collector only needs adding once
u.call_skill("yooasset_add_collector",
    packageName="DefaultPackage", groupName="HotUpdateCode",
    collectPath="Assets/HotUpdateDlls",
    addressRule="AddressByFileName", packRule="PackDirectory")
u.call_skill("yooasset_build_bundles",
    packageName="DefaultPackage", buildTarget="Android", packageVersion="auto")

Where the boundary sits: runtime loading is game code you write, not a skill. Load the .bytes TextAsset through YooAsset, then RuntimeApi.LoadMetadataForAOTAssembly(aotBytes, HomologousImageMode.SuperSet) for each AOT metadata DLL before Assembly.Load(hotUpdateBytes). Order matters. See yooasset-design for the handle-lifecycle rules.

When to re-run generate_all: only when AOT-side code changes (anything outside the hot-update asmdefs), when you add/remove a hot-update assembly, or before shipping a new player build. Generic instantiations reachable only from new hot-update code also require it — that is what AOTGenericReferences.cs records.

Critical Rules (must read)

1. hybridclr_status is the only skill that works without the package. Every other skill returns MISSING_PACKAGE. Unlike the YooAsset module there is no compile define — detection is pure reflection, so no recompile is needed after installing.
2. hybridclr_compile_dlls, hybridclr_generate_all and hybridclr_generate_step block the Editor main thread. UnitySkills runs all skills on the main thread through a single queue, so /health and /jobs also stall for the duration. Raise the client timeout to at least 10 minutes; a socket timeout does not cancel the operation.
3. generate_all and generate_step step="aot_dlls" run a scripts-only BuildPipeline.BuildPlayer internally into HybridCLRData/StrippedAOTDllsTempProj/<target>. Both refuse to start when BuildPipeline.isBuildingPlayer is true. The step temporarily flips EditorUserBuildSettings.buildScriptsOnly and the platform "export project" flags, restoring them in a finally — an Editor crash mid-step can leave them changed.
4. patchAOTAssemblies must match the generated PatchedAOTAssemblyList. Run hybridclr_aot_generic_refs after any generation and copy missingFromSettings into hybridclr_settings_set(patchAOTAssemblies=[...]). inSync=false means generic instantiations will throw at runtime. The generated list carries .dll suffixes and the setting does not; the skill compares on the stem, so pass either form.
5. Array parameters replace, they do not merge. hybridclr_settings_set(hotUpdateAssemblies=["A"]) discards any previously configured names. Read with hybridclr_settings_get first and pass the full intended array.
6. HybridCLRSettings is not an AssetDatabase asset. It is a ScriptableObject serialized to ProjectSettings/HybridCLRSettings.asset via InternalEditorUtility.SaveToSerializedFileAndForget, so it will not appear in asset_* skills, and Unity's undo stack cannot revert the file — only the workflow snapshot can.
7. Path fields use two different bases. outputLinkFile and outputAOTGenericReferenceFile are relative to Assets/; hotUpdateDllCompileOutputRootDir and strippedAOTDllOutputRootDir are relative to the project directory. hybridclr_get_paths returns both the raw and absolute forms.
8. The upstream field is misspelled externalHotUpdateAssembliyDirs. The skill parameter is spelled correctly (externalHotUpdateAssemblyDirs) and maps to it; hybridclr_settings_get returns the upstream spelling under settings.
9. Hot-update code must live in an asmdef listed in hotUpdateAssemblyDefinitions (or a name in hotUpdateAssemblies). Code outside those assemblies is AOT and cannot be hot-updated — changing it requires a new player build.
10. hybridclr_validate_setup distinguishes errors from warnings. Errors block hot update entirely (no IL2CPP, libil2cpp unpatched, no hot-update assemblies). Warnings are staleness signals (DLLs not compiled yet, patchAOTAssemblies empty) that are normal early in setup.

Limitations

• No install skill. InstallerController.InstallDefaultHybridCLR() is reachable by reflection but deliberately not exposed: it clones two git repos over the network and copies the editor's entire il2cpp tree, with no progress reporting or cancellation, and would hold the main-thread queue for the whole time. Use the HybridCLR/Installer... window, or unity-cli in batch mode.
• Synchronous execution. These operations are not AsyncJobService jobs — HybridCLR's commands are synchronous main-thread Unity APIs with no step boundaries to pump, so there is no jobId to poll. Treat them as long blocking calls.
• Workflow undo is partial for generation. hybridclr_settings_set restores fully. hybridclr_compile_dlls and hybridclr_copy_hotupdate_dlls restore the affected directory from a file backup under Library/UnitySkills/HybridCLRBackups/. hybridclr_generate_all and hybridclr_generate_step restore only the two Assets-side artifacts (link.xml, AOTGenericReferences.cs) plus the hot-update DLL directory — intermediates under HybridCLRData/ and generated C++ under LocalIl2CppData-*/ are rebuildable and deliberately out of scope. Re-run the pipeline rather than relying on undo for those.
• Backups keep 5 generations per label. Older undo steps for compile_dlls / copy_hotupdate_dlls degrade to "added files removed, previous files not restored". Library/ is not version-controlled, so backups do not survive a Library wipe.
• No control over build processors. HybridCLR's IPreprocessBuildWithReport / IPostprocessBuildWithReport hooks (CheckSettings, CopyStrippedAOTAssemblies, PatchScriptingAssemblyList, the Xcode source injectors) run automatically during the player build and are not configurable from this module.
• Version drift is reported, not guessed. Reflection targets are anchored to 8.12.0. If a member cannot be resolved the skill returns MISSING_PACKAGE naming it, rather than silently doing nothing.
• hybridclr_aot_generic_refs parses generated text, not IL. patchedAOTAssemblyList is read exactly from the PatchedAOTAssemblyList initializer, but genericTypeCount counts comment lines in the generator's // {{ AOT generic types block and is an approximation. Pass includeContent=true when you need the file verbatim.

unity-cli fallback

Every generation entry point is a [MenuItem]-annotated public static parameterless method, so anything this module cannot do is reachable through -executeMethod in batch mode:

Running these headless avoids the main-thread blocking problem entirely — see unity-cli. Installation has no parameterless menu method; it must go through the Installer window.

Reflection Anchors

Every skill resolves these against the HybridCLR.Editor assembly. Verified against hybridclr_unity 8.12.0 source.

Note SettingsUtil.HotUpdateAssemblyNamesIncludePreserved throws when a name appears in both hotUpdateAssemblies and preserveHotUpdateAssemblies. The skills catch it and surface the message in resolveErrors / hotUpdateAssemblyResolveError rather than failing the call.

Version Scope

• Target: com.code-philosophy.hybridclr 8.12.0. All type names, member names and signatures above are taken from that Editor source.
• Minimum Unity: HybridCLR itself supports 2019.4.0+ / 2020.3.0+ / 2021.3.0+ / 2022.3.0+ / 2023.2.0+ / 6000.0.0+ (6000.3.0+ on the 6000.3 branch); hybridclr_install_status reports the exact minimum for the running editor. This Skill module is verified against Unity 2022.3 and 6000.3.
• IL2CPP only. Mono builds cannot use HybridCLR; hybridclr_validate_setup reports this as a blocking error.
• Older/newer package versions still work for anything whose members resolve; unresolved members are reported by name, not silently skipped.

Exact Signatures

For authoritative parameter names, defaults, and return fields, query GET /skills/schema?category=HybridCLR or unity_skills.get_skill_schema(). This document is a routing / best-practice guide, not the signature source.