Recommendations runs five built-in rules against the dependency graph and returns a ranked, actionable list. Every entry names the affected assembly, states an estimated time impact where one can be calculated, and links back to that assembly in the Dependency Explorer.
Triggers when: Assembly-CSharp exists in the graph and contains 5 or more scripts.
Any script without an Assembly Definition File falls into the implicit Assembly-CSharp assembly, which recompiles in full on any change to any script inside it. This rule produces one consolidated recommendation listing every affected script path, rather than one recommendation per file or folder — a per-file version of this rule would generate excessive noise on any project that hasn't adopted assembly boundaries yet.
Triggers when: a non-editor-only, non-test, user-owned assembly contains a script that references UnityEditor outside a #if UNITY_EDITOR guard.
CompileScope scans the first 50 lines of each script in the assembly, looking for a using UnityEditor line that isn't inside an #if UNITY_EDITOR / #endif block. This isn't just a compile-time concern — an unguarded UnityEditor reference in a runtime assembly will fail to compile on any non-editor build target, which is why this rule is High severity regardless of the assembly's cascade score.
Triggers when: an assembly's cascade score is at least 0.3 (30% of the project), its last compile time is at least 500 ms, at least 3 other assemblies depend on it directly, and it's user-owned.
This is the rule that most directly reflects Hot Paths' central metric. The recommendation suggests splitting the assembly into an interface assembly and an implementation assembly — the interface half can stay stable while the implementation changes, decoupling most of the cascade from routine edits.
Triggers when: a user-owned test assembly depends on another assembly with at least 50 scripts and at least 1000 ms last compile time.
Every large dependency meeting both thresholds is listed together in a single recommendation per test assembly. The suggested fix is extracting interfaces into lighter assemblies, so test compilation isn't coupled to full production-implementation rebuilds.
Triggers when: a genuine cycle exists between two assemblies via explicit .asmdef references (auto-referenced edges are excluded from this check).
Detected via depth-first search over the graph. A cycle is only reported if both assemblies involved are user-owned — a cycle that touches a vendored package can't be fixed from within your project, so surfacing it would be a recommendation with no possible action. Unity treats a genuine circular assembly reference as a compilation error, so this is always High severity.
Rules 2 through 5 only ever flag assemblies you can actually act on. An assembly counts as user-owned if it has no .asmdef path at all (boundaryless code, like Assembly-CSharp), or if its .asmdef is not sourced from a Unity package registry, a Git package, or a built-in package. Local and embedded packages are still considered user-owned, since those commonly represent code you're actively developing within the same project.
Severity (High / Medium / Low) is fixed per rule, but the display order within a severity tier is computed from three factors: the estimated time impact (capped contribution), a fixed bonus per rule type (circular dependencies and editor-in-runtime findings rank highest within their tier), and a small penalty for findings that affect fewer than 3 scripts. This keeps the highest-value, most broadly-impactful findings at the top of the list rather than strictly alphabetical or strictly by raw impact number.
The Recommendations list supports a text search (matches title and assembly name) and a severity filter — All, High, Medium, Low. Clearing the search restores the full list without losing the current severity filter.
Expanding a row shows the full description, the estimated impact (when calculable — some findings, like a circular dependency, have no meaningful single-number time estimate and show none), the affected script paths (up to the first 8, with a count of any remainder), and a View in Dependencies button that jumps directly to the affected assembly.
When no recommendations exist for the current project:
No optimization opportunities detected.
CompileScope checks every assembly for fan-out, unused references, and organization issues on every analysis — an empty Recommendations tab means none of the five rules currently apply, not that the check was skipped.
Two rules produce High-severity findings, and both represent things that can actually break a build, not just slow one down: editor code in a runtime assembly, since an unguarded UnityEditor reference fails to compile on a non-editor build target; and near-circular dependency candidates, since Unity treats a genuine cycle as a compilation error. Start here.
For Medium severity, start with the largest logical grouping of affected scripts for orphan scripts, not necessarily the whole codebase at once — a first .asmdef boundary around your most self-contained module is a reasonable starting point. For a high-cascade utility assembly, the interface/implementation split the recommendation suggests is the highest-leverage fix available for reducing domain-reload impact generally: code that only needs the interface no longer needs to rebuild when the implementation changes.
Test assemblies with heavy production dependencies are lower priority, since they only affect test-compile time — still worth fixing once a test suite has grown large enough that a heavy test-compile step adds up across a CI pipeline.
After each fix: let Unity compile, press Analyse Now (or let auto-rebuild handle it), confirm the recommendation is gone, and check Dependency Explorer for the assembly you changed to confirm the edges look the way you intended — not just that the warning disappeared. Recommendations don't need to be cleared all at once; the list simply reflects current state on every analysis, so working through High-severity items across a few sessions and letting Medium/Low accumulate as a backlog is a reasonable way to use this tab on an established codebase.
- Hot Paths
- Dependency Explorer
- API Reference — registering your own rules