CtrlK
BlogDocsLog inGet started
Tessl Logo

error-handling

Use when reviewing scripts, client components, bundles, or runtime behavior related to Implement proper error handling. Inspect both source code and the browser execution path so fixes target the real bottleneck or bug.

58

Quality

67%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/error-handling/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

57%

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

A well-organized, terse rule overview with clean progressive disclosure to a verified reference file. It loses points for an unnecessary justificatory opener, the absence of executable code in the body, and mode-style sections that lack explicit validation checkpoints.

Suggestions

Drop the opening justification sentence ('Unhandled errors crash applications...') — Claude already knows why error handling matters — and let the Quick Reference stand as the lead.

Add one small executable snippet in the body (e.g. a try/catch around an async fetch and a minimal React Error Boundary) so guidance is copy-paste ready rather than fully delegated to the reference.

Turn the Code Review section into a short sequenced checklist with an explicit 'verify in the browser' checkpoint (open the page, trigger the failing path, confirm the error is caught/logged) so the workflow has a real validation step.

DimensionReasoningScore

Conciseness

The body is mostly lean (terse bullets and directive sections), but the opener 'Unhandled errors crash applications, create poor user experiences, and make debugging impossible...' explains a concept Claude already knows, matching the mostly-efficient-but-includes-unnecessary-explanation anchor.

2 / 3

Actionability

Guidance is concrete ('Wrap async operations in try-catch blocks', 'Use Error Boundaries in React', 'flag exact imports, event handlers, runtime side effects') but offers no executable code in the body — examples are delegated to references/rule.md — fitting the some-concrete-guidance-but-incomplete anchor.

2 / 3

Workflow Clarity

The Check/Fix/Explain/Code Review sections read as parallel invocation modes rather than a sequenced workflow, and verification is only implied ('state how the change should be verified in the browser') with no explicit validation checkpoint, matching the steps-present-but-checkpoints-implicit anchor.

2 / 3

Progressive Disclosure

The body is a concise overview that clearly signals a single one-level-deep reference ('see references/rule.md', verified to exist), matching the clear-overview-with-well-signaled-one-level-deep-references anchor.

3 / 3

Total

9

/

12

Passed

Description

77%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A complete, third-person description with an explicit 'Use when' trigger and concrete inspection actions. It is weakened by trigger-term coverage that omits natural variations and a generic review prefix that blurs distinctiveness against sibling rules.

Suggestions

Add natural trigger variations users would actually say — e.g. 'Use when the user mentions try-catch, unhandled Promise rejections, error boundaries, or silent error swallowing.'

Replace the generic 'reviewing scripts, client components, bundles, or runtime behavior' prefix with error-handling-specific triggers so the description is distinguishable from sibling frontend-checklist rules.

DimensionReasoningScore

Specificity

Names multiple concrete actions and targets — 'reviewing scripts, client components, bundles, or runtime behavior' and 'Inspect both source code and the browser execution path' — matching the multiple-specific-actions anchor.

3 / 3

Completeness

Explicitly answers both what (review/inspect error handling) and when via the 'Use when reviewing...' trigger clause, matching the both-what-and-when anchor.

3 / 3

Trigger Term Quality

'error handling' is a natural term, but the description omits common user variations (try-catch, error boundaries, unhandled rejections) and leans on technical phrasing, fitting the some-keywords-but-missing-variations anchor.

2 / 3

Distinctiveness Conflict Risk

The 'Implement proper error handling' niche is distinct, but the 'reviewing scripts, client components, bundles, or runtime behavior' prefix reads as a shared template likely reused across sibling frontend-checklist rules, so overlap risk remains.

2 / 3

Total

10

/

12

Passed

Validation

93%

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

Validation15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
thedaviddias/Front-End-Checklist
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.