CtrlK
BlogDocsLog inGet started
Tessl Logo

ts-sdk-author

Design, build, verify, and publish production-grade TypeScript SDKs as npm packages inside a pnpm monorepo. Covers workspace layout, public API and module boundaries, plugin extension points, branded types and library-tuned tsconfig, tsdown bundling (vs tsup/tsc-only/unbuild), package.json exports with dual ESM+CJS and isomorphic conditions (browser/workers/RN/deno), Turborepo pipelines, publint and @arethetypeswrong/cli verification, changesets pre-release mode, npm dist-tags (latest/next/beta/rc/canary), and the alpha→beta→rc→stable release lifecycle. Triggers on: build a TS SDK, extract core library, package.json exports, dual ESM CJS, tsdown config, tsup vs tsdown, publint, attw, changesets prerelease, npm dist-tag, beta to rc, canary release, pnpm workspace SDK, isomorphic SDK, tsconfig library, npm provenance, shipping a TypeScript library.

75

Quality

94%

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

92%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-engineered skill body: fully executable configs and commands, a clearly sequenced seven-phase workflow with genuine validation checkpoints and error recovery, and accurate one-level-deep progressive disclosure into seven verified reference files. The only slack is mild redundancy between phases and the quick-reference tables, some pre-known semver exposition, and a provenance-focused closing section.

Suggestions

Cut the 'Source Skills' section (or compress it to the frontmatter metadata it duplicates) — it is composition provenance, not execution guidance, and its ~20 lines compete with context for no operational value.

Deduplicate guidance that appears both in phases and in the Quick Reference: pick one home for dist-tag meanings and bundler alternatives, and cross-reference from the other location instead of restating.

Drop or compress the semver ladder commentary that Claude already knows (e.g. the 0.x.y / patch lines) and keep only the SDK-specific pre-release transitions and changesets mechanics.

DimensionReasoningScore

Conciseness

The body is dense and mostly earns its tokens: executable configs, command sequences, and decision tables with very little concept-explanation padding. Minor over-explanation and redundancy remain: the semver identifier ladder is partially pre-known to Claude, bundler guidance appears in both Phase 3 and the Quick Reference table, dist-tag meanings are repeated in Phase 7 and the Release Tag table, and the closing "Source Skills" section is provenance metadata that does not guide execution. This fits 'efficient; minor instances of over-explanation that could be trimmed' rather than the every-token-earns-its-place anchor.

4 / 5

Actionability

Nearly everything is copy-paste ready: complete tsconfig.build.json, tsdown.config.ts, turbo.json, package.json exports maps, changesets pre-enter/exit command sequences, and concrete verification commands ("pnpm exec publint --strict", "pnpm pack" + sandbox install with node CJS/ESM resolution checks). Specific examples cover the common cases (dual ESM+CJS, subpath plugins, isomorphic conditions), matching the fully-executable top anchor; it is not pseudocode or high-level hints.

5 / 5

Workflow Clarity

Seven explicitly sequenced phases with real inter-phase dependencies stated ("Skip any phase and something will break later"), dedicated verification commands in Phase 6 wired into prepublishOnly, explicit error-recovery loops ("Recover from a mistaken latest: npm dist-tag add @acme/sdk@1.0.0 latest"), and a per-release Pre-Publish Checklist. This matches the top anchor: clear sequence, explicit validation steps, feedback loops for error recovery, and checklists for the complex release process.

5 / 5

Progressive Disclosure

SKILL.md acts as the unified workflow plus daily quick-reference, with each phase ending in a "Read next: references/<file>.md — §N" pointer whose section numbers match the actual reference headers (verified against workspace-and-layout.md and verification-and-publishing.md), plus a final Reference Files table mapping each file to a use-when scenario. All seven referenced files exist, references are exactly one level deep, clearly signaled, and easy to navigate — a match for the top anchor.

5 / 5

Total

19

/

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: third-person, action-led, comprehensive in scope coverage, and with an explicit and well-stocked trigger list. The only weakness is a handful of generic trigger phrases that carry minor overlap risk with adjacent npm-publishing skills.

DimensionReasoningScore

Specificity

Opens with concrete third-person actions ("Design, build, verify, and publish production-grade TypeScript SDKs as npm packages inside a pnpm monorepo") and comprehensively enumerates coverage: "tsdown bundling (vs tsup/tsc-only/unbuild)", "package.json exports with dual ESM+CJS and isomorphic conditions", "publint and @arethetypeswrong/cli verification", "changesets pre-release mode", "npm dist-tags". This matches the anchor for multiple specific concrete actions with comprehensive coverage; it is not merely naming the domain with generic actions.

5 / 5

Completeness

It explicitly answers both questions: what ("Design, build, verify, and publish production-grade TypeScript SDKs as npm packages inside a pnpm monorepo. Covers workspace layout, ... release lifecycle") and when ("Triggers on: build a TS SDK, extract core library, ... shipping a TypeScript library") with concrete trigger phrases. This is a textbook match for the anchor that clearly and explicitly answers both what AND when; the 'when' is not weakly implied as at score 3-4.

5 / 5

Trigger Term Quality

The explicit "Triggers on:" list gives comprehensive natural phrases and synonyms users would actually say: "build a TS SDK", "extract core library", "tsup vs tsdown", "beta to rc", "canary release", "isomorphic SDK", "shipping a TypeScript library", plus tool names (publint, attw, changesets prerelease). Coverage includes variations and abbreviation synonyms, matching the top anchor rather than the 'a few natural terms missing' anchor.

5 / 5

Distinctiveness Conflict Risk

The niche is clear (TS SDK authoring in a pnpm monorepo) and most triggers are distinctive tool names (tsdown, publint, attw, changesets prerelease) with minimal conflict risk. However a few trigger phrases ("package.json exports", "tsconfig library", "npm provenance") are generic enough to also fire for a closely related npm-publishing or TypeScript-tooling skill, which fits 'mostly distinct; minor overlap risk with closely related skills' better than the minimal-conflict anchor at 5.

4 / 5

Total

19

/

20

Passed

Validation

87%

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

Validation — 14 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (603 lines); consider splitting into references/ and linking

Warning

metadata_field

'metadata' should map string keys to string values

Warning

Total

14

/

16

Passed

Repository
mindfold-ai/Trellis
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.