Conciseness

The body is lean — a compact response-code table, a 5-item idempotency checklist, and a 3-step sequence with no re-explanation of concepts Claude already knows. Minor over-inclusion keeps it from anchor 5: the "When to Use This Skill" section largely repeats the frontmatter description, and the 10-link "Related Skills" list spends lines on cross-skill navigation rather than the skill's own task.

Actionability

Concrete, executable instruction-level guidance throughout: "Use raw body; reject invalid requests with 4xx", "return 2xx for duplicates", the response-code-to-provider-behavior mapping, and "Process event within transaction / Store event ID after successful processing". As an instruction-only skill the absence of code is acceptable, but there are minor gaps — e.g., no minimal inline example of extracting an event ID or verifying a signature before deferring to references — so it does not reach anchor 5's copy-paste-ready coverage.

Workflow Clarity

The core workflow is clearly sequenced — "Verify signature first", "Parse payload second", "Handle idempotently third" — with explicit checkpoints (reject invalid requests with 4xx; check event ID; return 2xx for duplicates). It falls short of anchor 5 because the error-recovery feedback loop (what to do when processing fails — 5xx retry vs. dead-letter queue) is not summarized in the body, only delegated to reference files; the checkpoints that are present keep it above anchor 3.

Progressive Disclosure

The body is a clean overview with a Quick Reference, and all seven referenced files exist and are well-signaled, categorized (Handler Sequence, Best Practices, Framework Guides), and exactly one level deep — the reference files link only to sibling files in the same bundle and to external provider docs, with no see-a-file-that-sees-a-file chains. This matches the anchor 5 structure of concise overview plus clearly organized one-level-deep references.

Specificity

The description lists several concrete coverage areas — "implementing the handler sequence (verify first, parse second, handle idempotently), idempotency, error handling, retry logic" plus three named frameworks — but opens with the generic framing "Best practices for webhook handlers" and uses topic nouns rather than verb-led actions. It exceeds anchor 3 (only 1-2 concrete actions) but falls short of anchor 5's fully comprehensive, action-verb coverage.

Completeness

Both questions are answered explicitly: the what is "Best practices for webhook handlers" with enumerated coverage areas, and the when is a concrete trigger clause — "Use when implementing the handler sequence..., idempotency, error handling, retry logic, or framework-specific issues with Express, Next.js, or FastAPI". This mirrors the anchor 5 good example's structure; it is not anchor 4 because the when-clause is already explicit and specific rather than needing more detail.

Trigger Term Quality

Good natural keywords users would actually say: "webhook handlers", "idempotency", "error handling", "retry logic", "Express, Next.js, FastAPI". A few natural terms are missing — "signature verification", "raw body", "endpoint", "payload" — so it does not reach anchor 5's comprehensive synonym coverage, but it clearly exceeds anchor 3's partial keyword set.

Distinctiveness Conflict Risk

It carves a clear niche (general webhook handler patterns: sequence, idempotency, retry logic) distinct from provider-specific skills, and the framework names add routing precision. However, a bare user mention of "webhooks" could plausibly route to the provider-specific sibling skills this repo also contains (stripe-webhooks, github-webhooks, etc.), which keeps it at anchor 4 rather than 5.