Conciseness

Code-first and dense: every section is annotated snippets or a decision table, with no explanation of React or library basics, and code comments carry non-obvious info (the exact HTTP request each call makes). Not 5: a few tokens don't earn their place — "Prefer smaller React components that do one thing" is generic React advice, and the closing bolded "ALWAYS follow these patterns..." directive is padded; not 3: beyond those minor spots there is no unnecessary explanation.

Actionability

Copy-paste-ready call signatures cover the common cases: reads (useSuspense/useCache/useQuery/useDLE/useLive), conditional fetch via null params, parallel loading with useFetch + React.use(), mutations (update/partialUpdate/push/unshift/delete/pagination), forms (useLoading), debounce, AsyncBoundary, Controller refresh calls, and Query derivation. Missing resource definitions are explicitly delegated ("For API definitions (like TodoResource), apply the skill 'data-client-rest'"), so examples are complete for the skill's scope. Not 4: coverage of common cases is comprehensive with exact parameters and returns.

Workflow Clarity

Where workflows exist they are clearly sequenced: debugging says to "inspect the page's store before reading code for the cause" via __DC__.controller/__DC__.actions, then points to a symptom-mapped guide; the refresh table gives an explicit decision sequence (have-value → set, one endpoint → fetch, all args → expireAll, hide-while-refetching → invalidate). Not 5: there are no explicit validation checkpoints or feedback loops; not 3: sequencing and decision points are present and unambiguous, and no destructive/batch workflow is prescribed that would require validation.

Progressive Disclosure

The body is an overview of patterns while all API detail lives one level deep in references/ (27 files, every path cited in the body verified to exist), each with a one-line description in the References section; inline links like [AsyncBoundary](references/AsyncBoundary.md) appear in context, and browser-tool files instruct "read only yours". Cross-links inside reference files are lateral sibling navigation, not nested chains. Not 4: the split is appropriate throughout — patterns in SKILL.md, reference detail in the bundle, with clear navigation.

Specificity

Multiple concrete actions are listed — "Read, change and render async and shared state", "loading and error states, mutations and forms, filtered or derived views, and debugging data that looks wrong or stale" — plus named entry points (useSuspense, useQuery, useController). Not 4: the action list spans reads, writes, forms, derived views, and debugging, covering the library's full surface rather than having minor gaps.

Completeness

Explicitly answers both: what — "Read, change and render async and shared state in React with @data-client/react"; when — "Use it for loading and error states, mutations and forms, filtered or derived views, and debugging data..." and "Use it in place of fetch in useEffect, or app-wide useState and context". Not 4: the 'when' is not merely present but explicit and specific, with concrete trigger phrases matching the anchor-5 example.

Trigger Term Quality

Good natural phrasing users would actually say: "loading and error states", "fetch in useEffect", "app-wide useState and context", "data that looks wrong or stale on screen". Not 5: common synonyms such as "data fetching", "server state", or "API calls / API data" (only "any data from an API" appears) are absent; not 3: multiple natural trigger phrases and variations are present.

Distinctiveness Conflict Risk

Scoped to a named package (@data-client/react) with named hooks, making it mostly distinct. Not 5: "Use it in place of fetch in useEffect, or app-wide useState and context" is a broad trigger that could also fire for users of react-query/SWR/Redux-style skills; not 3: the named library and hooks keep the niche clear with only minor overlap risk against closely related skills.