Content
85%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A well-engineered workflow skill: seven clearly sequenced steps with an explicit validation gate and feedback loop, executable Unity fixture code and fault-injection commands, and bulk engine/cert detail correctly split into one-level-deep reference files. The main gaps are the lack of executable examples for the Unreal and Mirror fixture paths and minor trimmable padding, including inline version-sensitive pins.
Suggestions
Add a minimal executable Unreal fixture snippet (e.g. a spec observing an OnRep_ invocation in a multi-process PIE run) and a Mirror fixture example — these two of three supported engines currently get only directional guidance.
Move time-sensitive version pins (NGO v2.11, XR v16.1 May 2026, Unity 6.0) into a short 'Version-sensitive details' section so state tables and commands stay evergreen.
Tighten the motivational 'When to use' paragraph and shorten the worked example's re-walk of Steps 1-7 to the inputs and the divergent outcome.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and mostly earns its tokens: per-engine state vocabularies, tc qdisc injection commands, XR clause IDs, and a full fixture example are exactly the domain knowledge Claude lacks. Minor over-explanation remains — the motivational paragraph citing Microsoft's certification guide, the worked example re-walking all seven steps, and inline time-sensitive version pins ("Netcode for GameObjects v2.11", "XR v16.1 May 2026 release notes", "Unity 6.0") that are not placed in a deprecated/old-patterns section. This is 'efficient with minor instances that could be trimmed' (4) rather than the noticeably padded level 3 or the fully lean level 5. | 4 / 5 |
Actionability | Concrete and executable in most places: a copy-paste-ready C# `[UnityTest]` host-migration fixture with real asserts, exact `tc qdisc … netem delay 200ms` / `loss 5%` / `reorder 25%` commands, named engine hooks (`OnRep_`, `NetworkVariable<T>`, `ROLE_*`, `isOwned`), and a literal gate-report format. It stops short of level 5 because the Unreal fixture path ('drive a multi-process test harness... use specs to observe OnRep_ invocations') and the Mirror path are described directionally without any executable example, leaving gaps for two of the three supported engines. | 4 / 5 |
Workflow Clarity | Seven explicitly sequenced steps, each with defined inputs and outputs, a risk-weighted sampling rule, and a final go/no-go gate with hard thresholds ('high-risk bucket is at 100 %', every cert-mapped clause covered) that 'refuses to advance to platform-cert submission'. Validation and a feedback loop are demonstrated concretely: the worked example ends in a NO-GO on an XR-015 flake with the required remediation, and the anti-patterns table enumerates failure modes with fixes. This matches the level-5 anchor (clear sequence, explicit validation, error-recovery loops, checklist-style gate). | 5 / 5 |
Progressive Disclosure | The body is a clear overview that pushes bulk detail one level deep into real, well-signaled bundle files: the per-engine state/authority tables live in references/engine-states.md (verified to exist and contain exactly that) and the fixture-to-XR mapping in references/cert-clauses.md (also verified, one level deep with no further nested skill references). Both references are introduced with explicit 'The full ... tables are in [references/...]' framing, and the remaining inline content (workflow, worked example, anti-patterns, limitations) is appropriately placed. | 5 / 5 |
Total | 18 / 20 Passed |