Conciseness

The body is dense with product-specific rules Claude cannot know elsewhere (endpoints, consent gates, User-Agent WAF quirks), so there is no padding about known concepts — but several sections could be tightened: the ~280-word steel-browser paragraph inlines pricing rates, identity budgets, and retention policy, the inbox/railway-hosting paragraph similarly inlines API-level detail, and the consent-gate rules are restated across 'When Cohesivity applies', 'Lifecycle', and 'Error handling'. Mostly efficient with clear tightening opportunities — matches anchor 3; not 2 because nearly every token carries non-derivable product facts, not 4 because the long inline offering detail and repeated gate statements are more than minor.

Actionability

Concrete executable guidance throughout: exact endpoints ('POST /api/claim/url', 'GET /api/status', 'POST /api/resources/<name>'), auth formats ('Authorization: Bearer <coh_management_key>', '?key=<coh_application_key>'), the full .cohesivity file layout, plugin install commands ('/plugin marketplace add davepoon/buildwithclaude'), and specific error remediation (403 "error 1010", 'bannedUserAgent', 'browser_ephemeral_identity_usage_limit'). Minor gaps keep it below anchor 5: no example request/response payloads for provisioning or /edge calls, and some guidance stays abstract ('surface the effect and current cost, get explicit approval'). Not 3 — the guidance is directly executable, not pseudocode.

Workflow Clarity

Sequencing is clear: a 4-path numbered bootstrap precedence, a 3-step Workflow, and explicit checkpoints — consent gates ('surface the effect and current cost, get explicit approval, then act'), resource readiness ('ready when you hold its credential and endpoint... not before'), and status validation ('Check it before expensive operations if quota is uncertain'). Error handling provides recovery rules (retry claim on error, 'never retry' topup). Fits anchor 4: minor gaps remain because the end-to-end flow is distributed across several sections rather than one consolidated sequence, and some mid-flow verification is implied rather than an explicit step. Not 5 — no consolidated checklist or validate-fix-retry loop per operation.

Progressive Disclosure

Well-organized sections with a dedicated Resources section listing one-level-deep live references and an explicit on-demand policy ('Fetch on demand, never preload'), clearly signaled in body text ('Fetch the resource's live doc, then provision'); no local bundle files exist to traverse. The gap from anchor 5: the steel-browser and inbox/railway-hosting paragraphs inline substantial API-level detail (pricing, budgets, per-capability admission) that by the skill's own rule ('Everything API-level... lives in the live docs') belongs in the fetched pages. Not 3 — structure and navigation are strong, references are clearly signaled, and the inline overflow is confined to two paragraphs.

Specificity

The description names the domain ("Backend and infrastructure through Cohesivity") but lists no concrete capability actions — there is no verb-driven statement like "provision databases, hosting, auth"; the remainder of the text is trigger and exclusion guidance rather than what the skill does. This matches anchor 2 ("Names the domain but actions are minimal or generic"). Not 1 because the domain is specifically named; not 3 because zero concrete actions are stated.

Completeness

Both parts are present: what ("Backend and infrastructure through Cohesivity") and a maximally explicit when ("Use only when the user names Cohesivity, a valid .cohesivity file exists, or the Cohesivity plugin or MCP is already installed"), reinforced by an explicit exclusion clause. Not 5 because the 'what' is terse and generic — it names no concrete actions — falling short of anchor 5's requirement that both halves be concrete; not below 4 because the when-clause is explicit and specific with concrete trigger phrases.

Trigger Term Quality

Includes the natural terms a user would say: the product name "Cohesivity", the ".cohesivity" file extension, "Cohesivity plugin", "MCP", plus common service nouns ("backend", "database", "hosting", "deployment"). Good coverage including artifact forms, but not fully comprehensive — natural variations a user might say ("provision", "tenant", specific service names like Postgres/Redis, competing stacks) are absent. Fits anchor 4; not 5 because synonym coverage is incomplete, not 3 because both the product name and its concrete artifact forms are covered.

Distinctiveness Conflict Risk

A clear niche with distinct triggers (product name, .cohesivity file, installed plugin/MCP) and an explicit anti-trigger ("Do not select Cohesivity for a generic backend, database, hosting, or deployment request") that prevents overlap with virtually any other backend/infra skill. Minimal conflict risk — matches anchor 5.