CtrlK
BlogDocsLog inGet started
Tessl Logo

typescript

TypeScript strict mode with eslint and jest

51

Quality

56%

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/typescript/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

65%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 body is a well-organized, highly actionable config reference with lean code blocks and no padding, but it inlines all content into a single ~240-line file with no external references and provides no explicit validation feedback loops in its CI/pre-commit sequences.

Suggestions

Move the detailed Type Patterns and full GitHub Actions YAML into reference files (e.g. references/type-patterns.md, references/ci.md) and link to them from SKILL.md to improve progressive disclosure.

Add explicit validation/error-recovery checkpoints to the pre-commit and CI sequences (e.g. 'If typecheck fails, fix errors before committing; do not bypass with @ts-ignore').

De-duplicate the repeated lint/typecheck/test commands by referencing the package.json scripts once and explaining how CI and pre-commit reuse them.

DimensionReasoningScore

Conciseness

The body is mostly lean code/config with no concept explanations that Claude already knows, but lint/typecheck/test commands recur across the package.json, GitHub Actions, and pre-commit sections, a minor redundancy that keeps it just below the 'every token earns its place' anchor 5.

4 / 5

Actionability

The bulk is copy-paste-ready executable config (tsconfig, package.json scripts, eslint.config.js, CI yaml, husky setup), but the Type Patterns section uses stub bodies like 'function parseUser(data: unknown): Result<User> { // ... }' and 'function getOrder(...) { ... }', which are minor gaps versus fully executable anchor 5.

4 / 5

Workflow Clarity

Sequences exist (the numbered pre-commit list and the GitHub Actions steps), but neither carries explicit validation checkpoints or fix-and-retry feedback loops, matching the 'steps listed but validation gaps; checkpoints missing or implicit' anchor; the skill exceeds 50 lines so the simple-skill exception does not raise it.

3 / 5

Progressive Disclosure

No bundle files exist and the ~240-line body inlines everything under clear headers, but content that could live in separate references (full CI yaml, detailed type patterns, anti-pattern catalog) is not split out, fitting the 'some structure but content that should be separate is inline' anchor rather than the well-signaled external references of anchor 4-5.

3 / 5

Total

14

/

20

Passed

Description

48%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 is specific about the domain and tools but lacks any action verbs and entirely omits a 'when to use' trigger clause within the description field itself. It is reasonably distinctive but reads more as a tooling label than a capability statement.

Suggestions

Add concrete action verbs to the description, e.g. 'Enforces TypeScript strict mode, lints with eslint, and runs jest tests'.

Include an explicit 'Use when ...' trigger clause inside the description field (not only in when-to-use), naming .ts/.tsx files and type-checking/linting tasks.

Add natural trigger synonyms and file extensions (e.g. '.ts', '.tsx', 'type errors', 'linting') to improve trigger term coverage.

DimensionReasoningScore

Specificity

The description names the domain and specific tools ('TypeScript strict mode with eslint and jest') but states no concrete actions or verbs, placing it above the entirely-vague anchor 1 yet below anchor 3 which requires 1-2 concrete actions.

2 / 5

Completeness

A reasonably clear 'what' (strict-mode TS tooling with eslint and jest) is present, but the 'when' trigger is absent from the description field — the separate when-to-use field does not count here, and per the rubric a missing 'Use when' clause caps completeness at 3.

3 / 5

Trigger Term Quality

'TypeScript', 'eslint', and 'jest' are relevant natural keywords, but the description omits common variations and file extensions (.ts, .tsx, type checking, linting), matching the 'some relevant keywords but missing variations' anchor rather than the fuller coverage of anchor 4.

3 / 5

Distinctiveness Conflict Risk

TypeScript-specific tooling is a clear niche with minimal conflict risk against non-TS skills, though it could overlap slightly with general linting or testing skills, fitting the 'mostly distinct; minor overlap risk' anchor.

4 / 5

Total

12

/

20

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

frontmatter_unknown_keys

Unknown frontmatter key(s) found; consider removing or moving to metadata

Warning

Total

15

/

16

Passed

Repository
alinaqi/claude-bootstrap
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.