Conciseness

The body is dense with proprietary knowledge Claude cannot already know (iii engine/SDK error codes, retryability rules) and assumes competence throughout. Minor trims remain: the "When to Use" section restates the frontmatter description, and version-sensitive numbers ("(0.25)", "engine is older than 0.25") sit outside any old-patterns/deprecated framing. Efficient overall, so 4 rather than the every-token-earns-its-place 5.

Actionability

Copy-paste-ready, executable branching examples for Node ("error instanceof InvocationError && error.code === 'FORBIDDEN'"), Python ("except InvocationError as exc"), and Rust ("Err(iii_sdk::Error::Remote { code, message, .. })"), plus per-code handling columns. The Browser section ("Preserve the engine-provided code/message when present") and observer-error handling are prose/table only with no code, which are minor gaps — the 4 anchor rather than fully-executable 5.

Workflow Clarity

The core action is unambiguous and stated upfront ("Agents should branch on the error code instead of matching only message strings"), with a decision path organized across Error Codes → Handler vs Engine → Retryability. There is no explicit validate-then-act sequence for assembling a diagnosis, and no decision tree, so it sits below the 5 anchor's explicit checkpoints while clearly above the 3 anchor's implicit sequence.

Progressive Disclosure

No bundle files exist and the ~125-line body is well-sectioned with clearly signaled one-level-deep deferrals ("For observer states, filters, and owner hooks, prefer iii-observe"; "For SDK-specific exception classes and syntax, prefer iii-sdk-reference"). Minor gap: the full Observer Errors code table (~10 rows plus obs.call codes) is inlined even though the Pattern Boundaries section defers observer detail to iii-observe, so a leaner summary or a reference file would fit better — good structure overall, matching 4 rather than the well-split 5.

Specificity

Enumerates several concrete capabilities — "interpreting error codes, retryability, RBAC denial, timeouts, handler failures, or SDK-specific exception surfaces" — plus platform coverage ("Node, Python, Rust, and browser workers"). The lead verb "Handle ... errors" is generic, so coverage is strong but not the multiple distinct concrete actions of the 5 anchor; well above the 1-2 concrete actions of the 3 anchor.

Completeness

Explicitly answers both: what — "Handle iii engine and SDK errors across Node, Python, Rust, and browser workers"; when — "Use when interpreting error codes, retryability, RBAC denial, timeouts, handler failures, or SDK-specific exception surfaces". The "Use when" clause lists concrete trigger phrases, matching the 5 anchor; the 4 anchor requires a 'when' that could be more explicit, which does not apply.

Trigger Term Quality

Good natural keyword coverage: "error codes", "timeouts", "RBAC denial", "retryability", "handler failures" are phrases a user debugging an iii call would actually say. A few common variations are missing (e.g., "exception", "failed invocation", "error message"), which keeps it below the comprehensive synonym coverage of the 5 anchor but clearly above the generic-keyword 3 anchor.

Distinctiveness Conflict Risk

Clear niche ("iii engine and SDK errors") with distinct error-centric triggers, so it will not fire for unrelated skills. Minor overlap remains with closely related iii skills — "SDK-specific exception surfaces" treads on iii-sdk-reference territory and observer errors overlap iii-observe — matching the 4 anchor rather than the minimal-conflict 5 anchor.