Configure Clerk webhooks and handle authentication events. Use when setting up user sync, handling auth events, or integrating Clerk with external systems via Svix webhooks. Trigger with phrases like "clerk webhooks", "clerk events", "clerk user sync", "clerk svix", "clerk event handling".
85
83%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a well-structured skill description with strong trigger terms, explicit 'Use when' guidance, and clear distinctiveness. Its main weakness is that the capability description could be more specific about the concrete actions performed (e.g., verifying webhook signatures, handling specific event types like user.created). Overall, it's a solid description that would perform well in skill selection.
Suggestions
Add more specific concrete actions like 'verify webhook signatures', 'parse user.created/user.updated events', or 'configure webhook endpoints' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Clerk webhooks, authentication events) and some actions (configure, handle, sync), but doesn't list multiple specific concrete actions like endpoint setup, event parsing, signature verification, or specific event types handled. | 2 / 3 |
Completeness | Clearly answers both 'what' (configure Clerk webhooks, handle authentication events) and 'when' (explicit 'Use when' clause with specific scenarios plus a 'Trigger with phrases' section listing exact trigger terms). | 3 / 3 |
Trigger Term Quality | Excellent coverage of natural trigger terms including 'clerk webhooks', 'clerk events', 'clerk user sync', 'clerk svix', 'clerk event handling', plus mentions of 'auth events' and 'Svix webhooks' — these are terms users would naturally use. | 3 / 3 |
Distinctiveness Conflict Risk | Very distinct niche — Clerk-specific webhook configuration with Svix is highly specific and unlikely to conflict with generic webhook or authentication skills. The combination of Clerk + webhooks + Svix creates a clear, unique identity. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, highly actionable skill with excellent workflow clarity and real-world production considerations (idempotency, error handling table, enterprise notes). Its main weakness is length—the dual implementation approaches (verifyWebhook vs manual Svix, Next.js vs Express) and verbose event handlers make it token-heavy. Splitting alternatives and detailed handlers into referenced files would improve conciseness and progressive disclosure.
Suggestions
Extract the Express.js alternative (Step 6) and/or the manual Svix verification (Step 2 Alternative) into a separate reference file to reduce the main skill's token footprint.
Consolidate the repetitive user.created/user.updated event handler code into a shared helper pattern to demonstrate the approach more concisely.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly comprehensive but includes some redundancy—two full alternative implementations for Step 2, and the Express.js example in Step 6 largely duplicates the Svix verification pattern. The event handler code is quite lengthy with repetitive patterns (user.created and user.updated share most of their structure). However, it avoids explaining basic concepts Claude already knows. | 2 / 3 |
Actionability | Excellent actionability with fully executable TypeScript code for both Next.js and Express.js, complete with proper imports, error handling, and realistic database operations. The code is copy-paste ready, includes critical gotchas (req.text() vs req.json()), and covers the full lifecycle from setup to production considerations. | 3 / 3 |
Workflow Clarity | Clear numbered steps from dependency installation through endpoint creation, event handling, idempotency protection, and dashboard configuration. Includes explicit validation (signature verification with error responses), idempotency as a dedicated step with error recovery (processing → completed/failed states), and a comprehensive error handling table with causes and solutions. | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear sections and a helpful error table, but it's quite long (~200 lines of code) and could benefit from splitting detailed event handlers or the Express alternative into separate files. External resource links are provided but there are no bundle files to offload content to, and the inline content is heavy for a single SKILL.md. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
3a2d27d
Table of Contents
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.