code-standards

C# coding standards (Unity client)

This skill has two uses: setting the standard while writing code (sections 1–3), and running the review protocol during a review (section 4).

Its scope is C# and Unity. The reference files also carry the rules for Go, C++, Java, and Lua — consult those only when you are explicitly reviewing one of those languages. The protocol structure carries over, but perspective C in step 1 (asset and configuration evidence) is Unity-specific and must be swapped for that language's equivalent evidence dimension.

The core of the review protocol is its structure — parallel multi-perspective passes plus an independent final review — not the checklist. It is more precise and covers more than a single agent reading straight through, so don't skip the protocol and just read the checklist.

0. Precedence and applicability

A project's existing conventions take precedence over this skill's defaults. When you pick up a repository, first look for .editorconfig and analyzer configuration, gofmt and lint configuration, .clang-format, checkstyle, and the project's own documentation (CLAUDE.md, README, .cursor/rules/, and so on). Standards are often written in non-.md extensions like .mdc, so read the repository index before asserting "there is no standard." Once found, it governs, and citing its clauses requires the verbatim line number.

Rules come in two tiers: violating one marked [HARD RULE] fails the review; ones marked [DEFAULT] apply when the project has no convention of its own.

Hot paths (frame loop, combat, network send/receive, high QPS) enforce all performance clauses, and any path that every user interaction must traverse falls under the same clauses. The cold-path exemption covers only editor tooling, one-off scripts, and initialization code.

1. Goals for every line you write

The goals must be met; the approach is yours.

1. Peak algorithmic efficiency: think about the optimal order of magnitude before you start. What can be precomputed isn't computed at runtime, what can be incremental isn't done in full, what can be event-driven isn't polled.
2. Space discipline: choose by access pattern, allocate by budget. Predictable capacities must be pre-set; caches must have a cap and an invalidation policy.
3. Zero GC on hot paths: zero allocation within a frame in C# — eliminate boxing, closures, LINQ, string concatenation, and temporary collections. For per-language specifics see references/language-hard-rules.md.
4. High cohesion, low coupling: single responsibility, one-directional dependencies. For the criteria see references/cohesion-coupling.md.
5. Consistent naming and style: names must read as semantics, carrying units and direction. For C# specifics see references/naming-conventions.md.