error-monitoring

Use when setting up a new project's production observability stack, reviewing incident response readiness, or investigating why errors are going undetected.

Quality

51%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/error-monitoring/SKILL.md

Quality

Content

61%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is a well-structured overview that appropriately delegates detail to a single reference file with concrete, actionable guidance throughout. Main gaps are the motivational intro padding and the absence of an explicit verification step in the integration workflow.

Suggestions

Trim the introductory motivational paragraph to one sentence or remove it; the "why" is largely self-evident to Claude.

Add an explicit validation checkpoint to the Fix/Quick Reference flow, e.g. "Verify: trigger a test error and confirm it appears with release tag and user context in the dashboard before routing alerts."

Link `references/rule.md` inline beside the Quick Reference / Fix sections rather than only as a trailing note, so the handoff is contextual.

Dimension	Reasoning	Score
Conciseness	The body is mostly efficient, but the opening paragraph ("Users rarely file detailed bug reports — they simply leave", "cutting mean time to detect from days to minutes") is motivational context Claude already knows and could be trimmed.	3 / 5
Actionability	The Quick Reference and Check/Fix/Code Review sections give concrete, specific guidance naming real SDKs (Sentry, Datadog, Bugsnag), exact signals to capture, and specific review flags; code lives in the reference file, which is acceptable for this instruction-style overview.	4 / 5
Workflow Clarity	The Quick Reference implies a loose install→capture→tag→alert→RUM sequence, but the body is a categorized task framework (Check/Fix/Explain/Code Review) rather than a sequenced workflow, and there is no explicit validation checkpoint (e.g., confirm events appear in the dashboard).	3 / 5
Progressive Disclosure	The SKILL.md is a concise overview that delegates full implementation, code examples, and framework guidance to a single one-level-deep reference (`references/rule.md`); the pointer is clear but appears as a trailing general note rather than inline-linked beside the relevant sections.	4 / 5
	Total	14 / 20 Passed

Description

41%Weight 40%Scale 1-5

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 provides a strong, specific "when" trigger but omits any explicit "what" statement of capability, and its trigger terms lean broad relative to the skill's actual error-monitoring niche. Adding a leading capability sentence and tighter error-monitoring keywords would raise completeness and distinctiveness.

Suggestions

Prepend a concrete capability clause, e.g. "Integrate a real-time error monitoring SDK to capture unhandled exceptions, promise rejections, and release-tagged events. Use when..." so both what and when are explicit.

Add natural synonyms users actually say — "error tracking", "Sentry/Datadog setup", "production errors", "error reporting" — to broaden trigger term coverage.

Narrow the broad triggers ("observability stack", "incident response readiness") toward error detection specifically to reduce overlap with general observability or incident-response skills.

Dimension	Reasoning	Score
Specificity	The description names the domain plus three concrete scenarios ("setting up a new project's production observability stack", "reviewing incident response readiness", "investigating why errors are going undetected"), but these are trigger contexts rather than the skill's concrete capabilities (install SDK, capture exceptions, configure alerts), so coverage is not comprehensive.	3 / 5
Completeness	Only the "when" is present via a rich "Use when..." clause; there is no explicit "what" stating what the skill does, matching the anchor where only 'when' is present without 'what'.	2 / 5
Trigger Term Quality	Natural scenario phrases like "production observability stack" and "errors are going undetected" are present, but common synonyms users would say (error tracking, Sentry, error reporting, production errors) are missing.	3 / 5
Distinctiveness Conflict Risk	Two of the three triggers ("production observability stack", "incident response readiness") are broader than error monitoring and could overlap with general observability or incident-response skills, though the undetected-errors focus adds some specificity.	3 / 5
	Total	11 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning

	Total	15 / 16 Passed

Repository: thedaviddias/Front-End-Checklist
Path: skills/error-monitoring/SKILL.md
Commit: 30756a7

Reviewed: 4 days ago

Table of Contents

Discovery Implementation Validation

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.