clerk-observability
Implement monitoring, logging, and observability for Clerk authentication. Use when setting up monitoring, debugging auth issues in production, or implementing audit logging. Trigger with phrases like "clerk monitoring", "clerk logging", "clerk observability", "clerk metrics", "clerk audit log".
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-observability/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 completeness and trigger term coverage. Its main weakness is that the capability descriptions are somewhat high-level—listing broad categories (monitoring, logging, observability) rather than specific concrete actions. The explicit 'Use when' and 'Trigger with' clauses are well-structured and make it easy for Claude to select this skill appropriately.
Suggestions
Add more specific concrete actions, e.g., 'Track authentication failures, configure webhook event logging, set up error rate alerting, generate audit trails for user sign-in/sign-out events.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Clerk authentication) and some actions (monitoring, logging, observability), but doesn't list specific concrete actions like 'track failed login attempts', 'set up webhook event logging', or 'configure error alerting'. The actions listed are broad categories rather than specific capabilities. | 2 / 3 |
Completeness | Clearly answers both 'what' (implement monitoring, logging, and observability for Clerk authentication) and 'when' (setting up monitoring, debugging auth issues in production, implementing audit logging) with explicit trigger phrases listed. | 3 / 3 |
Trigger Term Quality | Includes good natural trigger terms: 'clerk monitoring', 'clerk logging', 'clerk observability', 'clerk metrics', 'clerk audit log'. These are terms users would naturally use when seeking this functionality, and the explicit trigger phrase list covers common variations. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive with the combination of 'Clerk' + 'monitoring/logging/observability'. The specific product name (Clerk) combined with the operational domain (monitoring, audit logging) creates a clear niche unlikely to conflict with other skills. | 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 skill provides highly actionable, executable TypeScript code for Clerk observability across six well-defined areas. However, it is overly long for a SKILL.md, lacking validation checkpoints between steps and missing progressive disclosure through supporting files. The content would benefit from being restructured as a concise overview with detailed implementations in separate bundle files.
Suggestions
Add validation checkpoints after each step (e.g., 'Verify auth events appear in logs by triggering a sign-in' after Step 1, 'Confirm Sentry receives test events' after Step 4).
Split detailed code implementations into bundle files (e.g., sentry-clerk-setup.md, webhook-monitoring.md) and keep SKILL.md as a concise overview with references.
Fix the middleware example in Step 2 — creating a new `Response` object discards the actual request handling; show the correct Next.js middleware pattern with `NextResponse.next()` and header modification.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is fairly long with six substantial code blocks. Some code is reasonable (auth-logger, health check), but the middleware example has issues (creating a new Response instead of using Next.js middleware patterns), and the dashboard metrics endpoint feels like padding. The error handling table and output summary add some redundancy. | 2 / 3 |
Actionability | All six steps provide fully executable TypeScript code with proper imports, file paths, and realistic implementations. The code is copy-paste ready with concrete patterns for Pino logging, Sentry integration, webhook tracking, and health checks. | 3 / 3 |
Workflow Clarity | Steps are clearly numbered and sequenced, but there are no validation checkpoints between steps. For a monitoring setup involving multiple integrations (Sentry, Pino, webhooks, health checks), there should be verification steps to confirm each integration is working before proceeding to the next. No feedback loops for error recovery. | 2 / 3 |
Progressive Disclosure | The content is a monolithic wall of code blocks that could benefit from splitting detailed implementations into separate files (e.g., sentry-setup.md, webhook-monitoring.md). The reference to 'clerk-incident-runbook' in Next Steps is good, but the main body is too long for a SKILL.md overview. No bundle files exist to offload detail. | 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 | |
- 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.