Conciseness

The body is dense and assumes competence — nearly every line carries non-obvious internal contracts (route ids, prop semantics, component names) rather than concepts Claude already knows, so it sits above anchor 3. It stops short of anchor 5 because settings guidance recurs across three sections ("Agent Surface Contract", "Settings Direction", "The app's group in Settings") and some advisory prose ("Visual Direction And Workspace Variety") could be tightened.

Actionability

For an instruction-only skill the guidance is fully concrete and executable: copy-paste commands ("agent-native eject --list", "docs-search", "source-search"), exact API signatures ("buildSettingsRoute(page, sub?, { anchor? })", "registerRequiredSecret({ kind: \"api-key\" })", "useLab(LAB_DEFINITION)"), a credential-classification decision table, and named routes and props throughout. Specific examples cover the common cases, matching anchor 5.

Workflow Clarity

Two explicit sequenced checklists ("Discover Before Building" steps 1-4 and the nine-step "Implementation Checklist") are present with verification checkpoints ("Run a custom adapter against @agent-native/toolkit/conformance in the app's CI", "verify a real handoff"), matching anchor 4. It is not anchor 5 because validation is endpoint-style and feedback loops for error recovery (fix-and-retry) are absent, though the destructive/batch cap does not apply to this policy skill.

Progressive Disclosure

No bundle files exist (no references/, scripts/, or assets/), yet reference-grade detail is inlined in the overview: the settings page-id catalog, SettingsTabsPage prop semantics, and the 17-item design-system component list — content the body itself says belongs in the "toolkit-settings" documentation. Structure and external references are clearly signaled ("Related Skills", named docs), so this fits anchor 3 (good structure, but content that should be separate is inline) rather than 2.

Specificity

The 'what' is limited to "Inventory and ownership rules for shared Agent-Native workspace UI" — it names the domain and its two deliverables but lists no concrete actions, since the enumerated areas ("app chrome, settings, navigation...") are trigger contexts rather than capabilities. This matches anchor 3 (domain plus 1-2 concrete items), not 4 (no list of several specific actions) and not 2 (the domain is precisely named, not generic).

Completeness

It explicitly answers both questions: the 'what' ("Inventory and ownership rules for shared Agent-Native workspace UI") and a fully explicit 'when' ("Use before building app chrome, settings, navigation, sharing...") with ten concrete trigger phrases. This is a clear anchor-5 match rather than 4, since the 'when' clause is specific and multi-trigger, not merely present.

Trigger Term Quality

"app chrome, settings, navigation, sharing, collaboration, setup, history, comments, chat rails, agent UX, or repeated workspace behavior" gives good coverage of natural phrases a user in this workspace would say. It falls short of anchor 5 because each area appears only once — no synonyms or common variations are included.

Distinctiveness Conflict Risk

The niche — deciding whether shared Agent-Native workspace UI belongs in the toolkit or app-locally — is clear with distinct triggers like "chat rails" and "agent UX". Minor overlap risk remains because "sharing", "collaboration", and "setup" also name closely related skills, keeping it at anchor 4 rather than 5.