clerk-security-basics
Implement security best practices with Clerk authentication. Use when securing your application, reviewing auth implementation, or hardening Clerk configuration. Trigger with phrases like "clerk security", "secure clerk", "clerk best practices", "clerk hardening".
78
74%
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-security-basics/SKILL.mdQuality
Discovery
72%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has strong trigger term coverage and completeness with explicit 'Use when' and 'Trigger with' clauses, but suffers from a lack of specificity in what concrete actions the skill performs. It reads more like a category label ('security best practices') than a description of specific capabilities. Additionally, the use of second person ('your application') should be avoided per the rubric guidelines.
Suggestions
Replace 'implement security best practices' with specific concrete actions, e.g., 'Configure session management, set up CSRF protection, enforce token rotation, and review middleware authorization rules for Clerk authentication.'
Rewrite in third person voice — change 'securing your application' to 'securing applications' or 'hardening Clerk auth configurations' to avoid the second-person penalty.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description says 'implement security best practices' which is vague and abstract. It does not list any concrete actions like 'configure CSRF protection', 'set up session management', or 'implement rate limiting'. The phrase 'securing your application' and 'hardening Clerk configuration' are similarly non-specific. | 1 / 3 |
Completeness | The description answers both 'what' (implement security best practices with Clerk authentication) and 'when' (securing application, reviewing auth implementation, hardening Clerk configuration) with explicit trigger phrases. Both components are present and clearly stated. | 3 / 3 |
Trigger Term Quality | The description includes explicit trigger phrases like 'clerk security', 'secure clerk', 'clerk best practices', 'clerk hardening' which are natural terms users would say. These are well-chosen and cover common variations of how a user might request this skill. | 3 / 3 |
Distinctiveness Conflict Risk | The Clerk-specific focus provides some distinctiveness, but 'security best practices' and 'securing your application' are broad enough to potentially overlap with general security skills or other auth-related skills. The Clerk branding helps but the security domain is wide. | 2 / 3 |
Total | 9 / 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 well-sequenced security hardening steps and fully executable code examples. Its main weakness is length — at ~180+ lines of content it pushes the boundary of what should be in a single SKILL.md without supporting bundle files, and includes some sections (Prerequisites, Output summary, Resources) that don't add much value for Claude. The workflow is well-structured with clear validation checkpoints embedded in each step.
Suggestions
Remove the 'Prerequisites', 'Output' summary, and 'Resources' sections — they add little actionable value and consume tokens.
Extract the rate limiting example and error handling table into a separate bundle file (e.g., CLERK-SECURITY-ADVANCED.md) and reference it from the main skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The content is mostly efficient with executable code examples, but includes some unnecessary sections like 'Prerequisites' (understanding of OWASP is not actionable), the 'Output' summary section that restates what was already shown, and the 'Resources' links that Claude already knows about. The error handling table adds value but the overall structure could be tighter. | 2 / 3 |
Actionability | Every step includes fully executable, copy-paste-ready TypeScript/bash code with specific imports, function signatures, and concrete patterns. The examples cover real scenarios (middleware, API routes, webhooks, rate limiting) with specific libraries and configurations rather than abstract guidance. | 3 / 3 |
Workflow Clarity | The 5-step sequence is logically ordered from foundational (env vars) through middleware, API routes, webhooks, to session security. Each step includes validation patterns (assertServerOnly check, header verification, auth checks before proceeding). The API route example explicitly numbers its defense-in-depth layers (1. auth, 2. authz, 3. input validation, 4. rate limiting). | 3 / 3 |
Progressive Disclosure | The content is a long monolithic file (~180 lines of substantive content) with no bundle files to offload detail into. The rate limiting example could be a separate reference, and the error handling table and session dashboard configuration could be split out. However, the section headers provide reasonable navigation within the single file. | 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 | |
- Commit
3a2d27d
- Reviewed
Table of Contents
Is this your skill?
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.