CtrlK
BlogDocsLog inGet started
Tessl Logo

typescript-advanced-practices

Type-first TypeScript coding practices — designing types before implementation, making illegal states unrepresentable with discriminated unions, runtime validation with Zod at system boundaries, and module organization (single-function modules, barrel files, encapsulation). Use when starting a new feature by asking what the types should look like first, spotting an interface with too many optional fields that let impossible combinations compile, or deciding how to validate data coming from outside the type system (an API response, form input, environment variables).

71

Quality

88%

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

SKILL.md
Quality
Evals
Security

Quality

Content

80%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.

A well-structured, actionable skill body: executable BAD/GOOD examples for every anti-pattern and clean one-level-deep reference navigation. Its weak point is workflow clarity — the practices are listed but not sequenced into a process with validation checkpoints, and the trigger conditions are duplicated across two sections.

Suggestions

Sequence the four practices into an explicit ordered workflow (e.g., 1. design the types, 2. model mutually exclusive states as a union, 3. validate at the boundary, 4. organize modules) with `npx tsc --noEmit` as an explicit validation checkpoint after design and after each change.

Merge the overlapping "When to Apply" and "Use When" sections into one, keeping the concrete user phrasings and dropping the restated bullet list.

Tighten the Mindset paragraph to the actionable rule (design types first; optional-field interfaces are unmodeled unions; validate once at the boundary) without the explanatory justification clauses.

DimensionReasoningScore

Conciseness

The body is efficient and opinionated rather than tutorial-style, but "When to Apply" and "Use When" restate the same triggers in two forms, and the Mindset paragraph ("a type is a specification the compiler checks on every subsequent change...") is longer than needed. Not 5: visible redundancy that could be trimmed.

4 / 5

Actionability

Each anti-pattern comes with complete, executable BAD/GOOD TypeScript pairs (the FetchState discriminated union, Zod's UserSchema.parse at the fetch boundary, the encapsulated db.ts module), plus runnable commands (npx tsc --noEmit). The examples are copy-paste ready and cover the common cases for each practice.

5 / 5

Workflow Clarity

The four practices are presented as parallel sections rather than a sequenced workflow — the implied order (design types → model unions → validate at boundary → organize modules) is never made explicit, and `npx tsc --noEmit` appears as a bare quick command rather than a validation checkpoint inside any workflow. Not 4: sequence and checkpoints remain implicit.

3 / 5

Progressive Disclosure

The body is a clear overview with a well-signaled References table pointing to four one-level-deep files (type-first.md, illegal-states.md, runtime-validation.md, module-patterns.md), all verified to exist and match their described coverage, plus two clearly labeled external links.

5 / 5

Total

17

/

20

Passed

Description

96%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.

A strong description: concrete capability list, explicit and natural "Use when" triggers, and a well-defined TypeScript type-design niche. The only weakness is minor overlap risk with closely related sibling TypeScript skills, which the description does not boundary-delineate itself.

DimensionReasoningScore

Specificity

The description lists four concrete actions — "designing types before implementation", "making illegal states unrepresentable with discriminated unions", "runtime validation with Zod at system boundaries", and "module organization (single-function modules, barrel files, encapsulation)" — which is comprehensive coverage of the skill's capabilities with no vague padding.

5 / 5

Completeness

Both "what" (the four concrete practices) and "when" (an explicit "Use when starting a new feature..., spotting an interface with too many optional fields..., or deciding how to validate data coming from outside the type system") are clearly and explicitly answered with concrete trigger phrases.

5 / 5

Trigger Term Quality

Natural user phrasings appear throughout: "an interface with too many optional fields", "an API response, form input, environment variables", "what the types should look like" — the terms users would actually say when needing this skill, plus the library name "Zod". Not 4: no commonly-used natural terms are missing for this domain.

5 / 5

Distinctiveness Conflict Risk

The niche (type-first design discipline, Zod boundary validation) is distinct with specific triggers, but sibling TypeScript skills referenced in the body (typescript-type-system, typescript-type-guards) create minor overlap risk that the description itself does not fence off.

4 / 5

Total

19

/

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

allowed_tools_field

'allowed-tools' contains unusual tool name(s)

Warning

Total

15

/

16

Passed

Repository
pantheon-org/tekhne
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.