Conciseness

The body is dense and mostly lean: a compact need→method table, terse numbered steps, short do/don't lists, and minimal boilerplate. It is not 5 because the 'Why' paragraph re-enumerates consequences ("rediscover auth, base paths, request-source headers, JSON parsing, error handling, optimistic updates, sync invalidation, and route quirks") — explanation that could be trimmed by a sentence — and the action-fetch-behavior paragraph carries detail that could partly live in a reference.

Actionability

Fully concrete guidance throughout: named hooks with exact import paths (`useActionQuery` / `useActionMutation` from `@agent-native/core/client/hooks`), an explicit call signature `callAction(name, params, { method, signal, timeoutMs })`, file-placement rules (`packages/core/src/client/*`, `templates/<app>/app/hooks/*`), and paired good/bad code examples. A developer can act on this directly without invention.

Workflow Clarity

The three-step decision sequence is clear and ordered: look for an existing client API (table), else add the narrowest helper with placement rules and 'Add focused tests for URL construction, headers, response parsing, error shape, and any sync invalidation', then teach the helper. It is not 5 because the validation guidance is a checklist mention rather than an explicit validate→fix→retry feedback loop, and the exceptions list is presented as cases rather than a decision checkpoint.

Progressive Disclosure

Clear sectioned overview (Rule / Why / How / Exceptions / Don't / Related Skills / References) with a single, well-signaled one-level-deep reference — `references/legacy-client-fetch-audit-2026-06-03.md` — which exists in the bundle and is described in place ('known legacy cleanup targets found when this rule was added'). Content is appropriately split: the SKILL.md holds the rule, the audit detail lives in the reference, and related skills are named for navigation.

Specificity

"Client method surface rules" names the domain and declares the skill type, and the trigger list enumerates concrete surfaces ("actions, application state, framework routes, app APIs, uploads, auth, or settings"), but the description itself states no concrete actions the skill performs — it is a capability statement, not an action list. It matches 'Names domain and 1-2 concrete actions, but not comprehensive' more than score 2 because the enumerated trigger surfaces are specific rather than generic, and it falls short of 4 because no operative actions (e.g., 'wrap raw fetch calls in named helpers', 'migrate route calls to action hooks') are listed.

Completeness

It explicitly answers both: what — "Client method surface rules"; when — "Use when wiring browser/client code to actions, application state, framework routes, app APIs, uploads, auth, or settings". The 'Use when' clause is explicit with concrete trigger phrases, matching the score-5 anchor exactly; it is not 4 because the trigger guidance is already specific and multi-faceted rather than merely adequate.

Trigger Term Quality

Natural terms a developer would say are present: "browser/client code", "actions", "application state", "framework routes", "uploads", "auth", "settings". This matches 'Good keyword coverage; a few natural terms missing' — common variations like "fetch calls", "API calls", "client hooks", or specific hook names are absent, keeping it below the synonym-and-extension coverage of a 5.

Distinctiveness Conflict Risk

The niche (client method surface rules for wiring browser code) is clear and distinct with domain-specific triggers. It is not 5 because broad trigger words like "auth", "settings", and "uploads" could plausibly fire for other skills covering those areas, creating minor overlap risk with closely related skills.