/scriptdesign

name: unity-scriptdesign
description: Advise on Unity gameplay script quality

> **Before calling any skill in this module:** if you are about to call a skill with parameters guessed from its name or description, STOP — read this file (or fetch its schema via `GET /skills/recommend?includeSchema=true`) first. If you already have the parameter definitions from recommend/schema, you may proceed straight to dryRun.

Triggers

• Reviewing code quality
• Untangling tightly-coupled scripts
• Planning a refactor for maintainability
• 审查代码质量、理顺高耦合脚本、为可维护性规划重构

Unity Script Design Review

Use this skill before creating gameplay scripts, or after scripts are generated and need a design pass.

Review Checklist

• Responsibility: does the script have one clear job?
• Role: should it really be a `MonoBehaviour`, `ScriptableObject`, or plain C# class?
• Coupling: are dependencies explicit instead of hidden globals or deep scene lookups?
• Communication: should this be a direct reference, interface call, or event?
• Performance: is there unnecessary `Update`, repeated `Find`, avoidable allocation, or reflection in hot paths?
• Lifecycle: are subscriptions, timers, and async work cleaned up clearly?
• Inspector UX: are serialized fields private, grouped, and explained?
• Testability: can the core logic move into a plain C# class?
• Naming: do class and field names explain intent without cryptic abbreviations?

Data Lifecycle Boundary

The Review Checklist above asks "where does this *class* live". Ask the same question for every *field*. Every piece of state has one of three lifecycles, and putting a field on the wrong one is the most common cause of "why did this break when the designer tweaked a value" and "why are my unit tests flaky".

| Lifecycle | When the value is decided | Where it belongs | Typical idiom | |-----------|--------------------------|------------------|---------------| | **Authoring-time** | By a designer in the Editor, before Play | `ScriptableObject` asset, or `[SerializeField] private` on a prefab | Immutable at runtime; read via `_config.Speed` | | **Composition-time** | Once per scene/instance, at `Awake`/`Start` | `private` field, assigned from `GetComponent` / `GetComponentInChildren` / ctor arg | Cached reference, no per-frame lookup | | **Runtime-mutable** | Every frame or on gameplay events | `private` backing field + `public` read-only property + event | Exposed via `public float Health { get; private set; }` + `OnHealthChanged` |

Typical assignments

• Weapon damage / fire rate / clip size → **Authoring-time** (ScriptableObject so balance can be hot-swapped).
• Enemy AI's current target `Transform` → **Composition-time** if set once at spawn, **Runtime-mutable** if re-targeted each frame.
• Player current HP → **Runtime-mutable** with event. Never `public float hp;`.
• Reference to `Rigidbody`/`Animator` on the same GameObject → **Composition-time**, cached in `Awake`.
• Level music track → **Authoring-time** via ScriptableObject level descriptor.
• "Is in combat" flag → **Runtime-mutable**, but usually derived from other state — review whether it should be a field at all.

Why the separation matters

Mixing the three lifecycles is what turns a clean class into a god object. A `MonoBehaviour` whose `public float speed` is edited by both the Inspector **and** a power-up script has two owners and no invariant; a bug in either path corrupts the other. The ECS baking pipeline makes this distinction a hard architectural boundary (Authoring → Baker → System), and the discipline transfers directly: if you would not mix an Authoring component with runtime write-back in ECS, do not mix them in a MonoBehaviour either. *Source: `EntitiesSamples/Docs/baking.md:5-16`.*

Guardrails

> **Mode**: Documentation only — no REST skills to gate; load freely under any operating mode (Approval / Auto / Bypass).

• Prefer descriptive names over local shorthand.
• Do not “optimize” readability away for imagined productivity gains.
• Do not recommend complex patterns if a smaller refactor fixes the real problem.

Output Format

• Keep: what is already good
• Simplify: what should stay straightforward
• Refactor: the highest-value structural change
• Performance notes: only real hotspots, not theoretical micro-optimizations
• Maintainability notes: naming, ownership, coupling, editor usability