CtrlK
BlogDocsLog inGet started
Tessl Logo

no-explicit-any

Use when reviewing TypeScript files for type safety regressions, during code review of functions that handle external data, or when the codebase has ESLint warnings for @typescript-eslint/no-explicit-any.

60

Quality

71%

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/no-explicit-any/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

70%

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

A clean, well-structured overview that delegates detail appropriately to a verified reference, with clear invocation modes; its main weaknesses are a conceptual intro paragraph and executable examples living only in the reference.

Suggestions

Trim or remove the opening conceptual paragraph about any propagating to callers — Claude already knows this — and keep only the actionable Quick Reference and mode directives.

Inline one minimal before/after code snippet (e.g. any → unknown with a type guard) in the Fix section so the body is actionable without requiring the reference.

Surface a one-line verification cue in the body (e.g. "confirm with eslint --rule @typescript-eslint/no-explicit-any") rather than leaving all verification steps in the reference.

DimensionReasoningScore

Conciseness

The body is mostly lean with useful Quick Reference bullets and terse mode directives, but the opening paragraph explains why any is harmful — a concept Claude already knows — so it could be tightened rather than earning full efficiency.

2 / 3

Actionability

Guidance is concrete and specific (enumerates explicit annotations, implicit any, assertions to any, and the unknown/generics/Zod replacements), but the executable code examples are offloaded to the reference and directives like "suggest a safer alternative" are slightly open-ended, keeping it below copy-paste-ready.

2 / 3

Workflow Clarity

As a simple single-purpose skill under 50 lines, the body is clearly organized into unambiguous invocation modes (Check / Fix / Explain / Code Review); the simple-skills exception applies and no destructive/batch feedback-loop cap is relevant.

3 / 3

Progressive Disclosure

The body is a concise overview with a well-signaled one-level-deep pointer ("see references/rule.md") whose target file exists and holds the detailed examples and verification steps, matching the clear-overview-with-one-level-reference anchor.

3 / 3

Total

10

/

12

Passed

Description

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.

A well-targeted, distinctive trigger description with strong natural keywords, but it folds the capability statement into the "Use when" clause rather than separately declaring what the skill does.

Suggestions

Lead with a short declarative what-statement before the triggers, e.g. "Reviews TypeScript code for any-type usage and suggests unknown, generics, or Zod alternatives. Use when..."

Name the concrete remediation actions (replace with unknown, add generics, validate with Zod) so the capability list is comprehensive rather than implied.

DimensionReasoningScore

Specificity

The description names the domain and an action ("reviewing TypeScript files for type safety regressions", "code review of functions that handle external data") but does not list multiple distinct concrete actions like the score-3 anchor; it is trigger-oriented rather than an action inventory.

2 / 3

Completeness

The "when" is explicit and multi-scenario ("Use when... during... or when..."), but the "what" is only embedded as a gerund inside the trigger clause rather than stated as a distinct declarative capability, so it does not clearly separate what from when as the score-3 anchor does.

2 / 3

Trigger Term Quality

Natural terms a user would say are well covered — "TypeScript files", "type safety", "code review", "external data", and "ESLint warnings for @typescript-eslint/no-explicit-any" — matching the kind of language users actually paste during review.

3 / 3

Distinctiveness Conflict Risk

The @typescript-eslint/no-explicit-any niche with type-safety-regression triggers is specific and unlikely to collide with other skills, giving it a clear distinct niche.

3 / 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.