Conciseness

The body is dense and error-driven: it assumes Zig competence, never explains what Zig or an allocator is, and every snippet shows only the before/after delta (e.g. "`std.ArrayList(T).init(allocator)` is gone; ... Initialize with `.empty` and pass the allocator to every call"). Minor trimming is possible — the long UiApp/effects paragraph inlines a dense list of fx.* verbs and permission rules that partially duplicates the native-ui skill. It is more efficient than the score-3 anchor (which has unnecessary explanation) but not perfectly lean like the score-5 example.

Actionability

Every fix is complete, executable Zig with exact signatures and argument orders ("readFileAlloc(io, path, allocator, .limited(1024 * 1024))", "std.process.spawn(io, .{ .argv = ... })"), plus live in-repo reference paths for each idiom (tools/native-sdk/main.zig, src/tooling/templates.zig). Copy-paste ready and covering the common failure cases, including the error-message string each old idiom produces.

Workflow Clarity

The lookup workflow is unambiguous and closed-loop: search by exact error text → apply the two resolving rules ("Operations on the outside world take a `std.Io` first" / "Containers are unmanaged") → apply the section's fix → validate with an explicit checkpoint ("run BOTH `zig build` and `zig build test` before calling a change done", justified by lazy analysis). The "Unchanged — do not 'migrate' these" section acts as a negative control preventing over-application. This matches the score-5 anchor's validate→fix→retry feedback loop.

Progressive Disclosure

No bundle files exist, so all content is in one ~200-line file. Structure is strong: each section header is the exact compile error (self-indexing navigation), and external navigation is clearly signaled one level deep ("see `native skills get native-ui`", "the generated ejected `build.zig` is the reference shape (`native eject`)"). It falls short of 5 because some content that could plausibly live in separate reference files (the UiApp effects-channel inventory, the build.zig module shapes) is inlined, matching the score-4 anchor's "minor organization gaps" rather than the 5 anchor's explicit multi-file split.

Specificity

"Zig 0.16 idioms for Native SDK code, indexed by compile error" plus "Covers main(std.process.Init), std.Io file IO and writers, ArrayList, process spawning, environment, clocks and sleep, sockets, custom formatting, and build.zig module shapes" names nine concrete coverage areas with real API names. This matches the score-5 anchor (multiple specific concrete actions, comprehensive coverage) rather than 4, since coverage gaps are negligible for the domain.

Completeness

Both halves are explicit: the what ("Zig 0.16 idioms for Native SDK code... Covers [nine areas], each as this SDK writes them") and the when ("Load when `zig build` fails on std APIs with errors like [six exact errors]"). Clearly matches the score-5 anchor with concrete trigger phrases; 4 would require the when-clause to be less explicit.

Trigger Term Quality

"Load when `zig build` fails on std APIs with errors like 'struct 'fs' has no member named 'cwd'', 'no member named 'GeneralPurposeAllocator'', 'no member named 'getEnvMap'', or 'invalid format string'" quotes the verbatim compiler messages a user hits, which are the most natural possible trigger phrases. Not 4 — no natural terms or synonyms are missing, including version markers (Zig 0.16, 0.15).

Distinctiveness Conflict Risk

The pairing of "Zig 0.16", "Native SDK", and verbatim 0.15-era compile errors carves a clear niche with essentially no overlap risk against other skills. It is more distinct than the score-4 anchor, which still allows minor overlap with closely related skills.