Conciseness

The body is dense with non-obvious operational knowledge (the CLI 50.25.0–53.2.x stderr-credential gotcha, the x-vercel-oidc-token vs x-vercel-trusted-oidc-idp-token distinction, dead ends like 'vercel share'), with essentially no padding or explanation of things Claude already knows. It falls short of anchor 5 only through minor tightening opportunities and pinned version numbers presented outside a deprecated/old-patterns section, though those versions function as a runtime gate rather than roting date-conditional instructions.

Actionability

Guidance is fully executable: 'vc whoami', 'vc project token "$VERCEL_PROJECT" --scope "$VERCEL_SCOPE"' inside a complete mint-and-inject block with a 'test -n "$TOKEN"' guard, the exact header 'x-vercel-trusted-oidc-idp-token', the protection-bypass fallback commands, and an error-signature-to-cause mapping. The common cases (same-project preview, cross-environment, static-secret fallback) are each covered with copy-paste-ready commands.

Workflow Clarity

The same-project preview path is clearly sequenced (identity/version check → scope → session → token mint → authenticated open → snapshot) with explicit validation checkpoints (version gate with stop-and-ask, non-empty token test) and genuine feedback loops: the 'Diagnose failures' section maps each failure to a cause and remedy, and the Trusted Sources path retries the authenticated open after human confirmation. No destructive or batch operations are involved, so no validation cap applies.

Progressive Disclosure

As a single-file skill with no references/, scripts/, or assets/ directories, the body is well-sectioned (same-project preview, other environments, intervention boundaries, header, diagnostics, fallback, dead ends) and everything reads at overview level. It sits at anchor 4 rather than 5 because at ~105 lines it exceeds the under-50-line simple-skill exception, and secondary material (the static-secret fallback and diagnostics detail) could arguably live in one-level-deep reference files.

Specificity

The description lists several concrete capabilities — 'Access and test Vercel deployments protected by Vercel Authentication, SSO, or Deployment Protection with agent-browser' and 'short-lived Trusted Sources OIDC authentication instead of a static bypass secret or public exception' — using third-person voice. It stops short of anchor 5 because the action list is narrow (essentially one access/test workflow) rather than comprehensive coverage of multiple distinct actions.

Completeness

It explicitly answers both questions: the 'what' ('Access and test Vercel deployments protected by... with agent-browser') and the 'when' with concrete trigger phrases ('Use when a preview or production URL redirects to a Vercel login page, returns a protection 401 or 403, or needs short-lived Trusted Sources OIDC authentication'). This clearly matches the anchor-5 example structure and is not merely the implicit-when of anchor 4.

Trigger Term Quality

Triggers like 'a preview or production URL redirects to a Vercel login page, returns a protection 401 or 403' are phrases a user would naturally encounter and say. A few natural terms are missing — notably 'password protection' (Vercel Authentication's former, still-common name), '.vercel.app', and generic 'can't access my deployment' phrasing — so it fits anchor 4 rather than the comprehensive synonym coverage of anchor 5.

Distinctiveness Conflict Risk

It carves out a clear niche — Vercel deployment protection bypassed via Trusted Sources OIDC — with distinct triggers (login redirect, protection 401/403, Trusted Sources) that no generic deployment or browser-automation skill would claim. Conflict risk with other skills is minimal, matching anchor 5.