Set up local development workflow with Clerk. Use when configuring development environment, testing auth locally, or setting up hot reload with Clerk. Trigger with phrases like "clerk local dev", "clerk development", "test clerk locally", "clerk dev environment".
80
77%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/saas-packs/clerk-pack/skills/clerk-local-dev-loop/SKILL.mdQuality
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 solid skill description with excellent trigger terms and completeness. Its main weakness is that the 'what' portion could be more specific about the concrete actions performed (e.g., configuring environment variables, setting up webhook tunnels, configuring middleware). The explicit trigger phrases and clear 'Use when' clause make it highly functional for skill selection.
Suggestions
Add more specific concrete actions to the 'what' portion, e.g., 'Configures environment variables, sets up webhook forwarding, configures Clerk middleware, and enables hot reload for local Clerk authentication testing.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (Clerk local development) and mentions some actions like 'configuring development environment', 'testing auth locally', and 'setting up hot reload', but these are fairly general and don't list concrete specific steps or outputs. | 2 / 3 |
Completeness | Clearly answers both 'what' (set up local development workflow with Clerk) and 'when' (configuring development environment, testing auth locally, setting up hot reload) with explicit trigger phrases provided. | 3 / 3 |
Trigger Term Quality | Includes explicit natural trigger phrases like 'clerk local dev', 'clerk development', 'test clerk locally', 'clerk dev environment' which are terms users would naturally say. Also includes broader terms like 'hot reload with Clerk' and 'testing auth locally'. | 3 / 3 |
Distinctiveness Conflict Risk | The description is narrowly scoped to Clerk local development specifically, with distinct trigger terms that are unlikely to conflict with other skills. The combination of 'Clerk' + 'local dev' creates a clear niche. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
64%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a solid, highly actionable skill with excellent executable code examples covering the full local dev workflow including seeding, mocking, and E2E testing. Its main weaknesses are the lack of validation checkpoints between steps (e.g., verifying the dev server connects to Clerk successfully) and the monolithic structure that could benefit from splitting test helpers into separate referenced files. Minor verbosity in explanatory sections could be trimmed.
Suggestions
Add validation checkpoints after key steps — e.g., after Step 1, verify keys work with a curl command to Clerk API; after Step 2, verify users were created by listing them.
Extract the mock helper (clerk-mock.ts) and Playwright fixture into separate bundle files and reference them from the main skill to improve progressive disclosure.
Remove the bullet list under 'Clerk development instances provide' — Claude knows these details and they aren't actionable instructions.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary explanations Claude would already know (e.g., listing what Clerk development instances provide, explaining prerequisites). The comments in code are generally useful but some sections like the 'Output' summary feel redundant given the step-by-step instructions already cover this. | 2 / 3 |
Actionability | The skill provides fully executable, copy-paste ready code throughout — TypeScript seed scripts, Next.js config, Vitest mock helpers, Playwright fixtures, and concrete bash commands. Every step has specific, runnable examples with realistic code. | 3 / 3 |
Workflow Clarity | Steps are clearly sequenced (Steps 1-5) and logically ordered, but there are no validation checkpoints or feedback loops. For example, after seeding test users there's no verification step, and after configuring hot reload there's no check that Clerk is actually working. The error handling table partially compensates but is reactive rather than integrated into the workflow. | 2 / 3 |
Progressive Disclosure | The content is well-structured with clear sections, but it's quite long (~150 lines of substantive content) with everything inline. The mock helpers and Playwright fixtures could reasonably be split into separate referenced files. The 'Next Steps' reference to 'clerk-sdk-patterns' is good, but no bundle files exist to support progressive disclosure. | 2 / 3 |
Total | 9 / 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.