CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

publishing-packages

Conventions for publishing npm packages from this repository, including when a PR needs a changeset and how to write one. Use when adding or editing a changeset, versioning or releasing a package, or deciding whether a change to a publishable library needs a changelog entry.

76

Quality

96%

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.

The body is an efficient, well-structured conventions document that adds only repo-specific knowledge and points to the right external locations (changeset config, per-package AGENTS.md). Its single weakness is the absence of a concrete changeset example showing the file format. As an instruction-only skill, the lack of code is not itself penalized.

Suggestions

Add a short example changeset (frontmatter with package name and bump type, one-paragraph body written from the consumer's perspective) so the common case of writing a changeset is fully covered.

Optionally state where the changeset filename convention comes from (e.g., that changeset filenames are arbitrary .md files under .changeset/) to remove the last ambiguity about file creation.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence: it states that packages are 'versioned and released with changesets' in one line and spends the rest on repo-specific conventions ('Every sentence must apply to each package the changeset lists', 'Use at most one paragraph per changeset'). Every token carries information Claude could not infer, so the 'could be tightened' level below does not apply.

5 / 5

Actionability

Guidance is concrete and directive — 'adds a changeset file under .changeset/', 'write a separate changeset for each package', 'check it before writing the changeset' — but there is no example of an actual changeset file (e.g., its frontmatter with package name and bump type), which is a minor gap against the anchor requiring specific examples to cover the common cases. It is not level 3 because nothing is vague or pseudocode; the directives are executable as written.

4 / 5

Workflow Clarity

This is a simple, single-purpose skill and the single action is unambiguous, with an explicit ordering cue ('A package's own AGENTS.md can carry further conventions... check it before writing the changeset'). Writing a markdown changeset is neither destructive nor a batch operation, so the validation-cap guideline does not apply and the simple-skill exception holds.

5 / 5

Progressive Disclosure

The skill is under 50 lines, needs no external reference files, and is well organized with a heading and bulleted conventions; the one pointer it does make ('The changeset configuration... lives in .changeset/config.json') is clearly signaled and one level deep, so the short-skill guideline for a top score is satisfied.

5 / 5

Total

19

/

20

Passed

Description

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

This is a strong description: third-person, concise, and free of fluff. It states concrete capabilities and pairs them with an explicit, specific 'Use when...' clause covering the decide/write/version/release use cases with natural synonyms (changeset, changelog entry).

DimensionReasoningScore

Specificity

The description lists multiple concrete actions — 'when a PR needs a changeset and how to write one', 'adding or editing a changeset', 'versioning or releasing a package', 'deciding whether a change to a publishable library needs a changelog entry' — which comprehensively covers the skill's domain, matching the top anchor rather than the 'minor gaps' level below it.

5 / 5

Completeness

It explicitly answers both questions: the 'what' ('Conventions for publishing npm packages from this repository, including when a PR needs a changeset and how to write one') and an explicit 'Use when...' clause with three concrete trigger conditions, matching the top anchor; the level-4 anchor's 'when could be more explicit' does not apply here.

5 / 5

Trigger Term Quality

Natural trigger terms users would actually say are present and include synonyms: 'changeset', 'changelog entry', 'versioning', 'releasing', 'npm packages', and 'PR'. No common phrasing for this domain is missing, so it fits the comprehensive-coverage anchor rather than the 'a few natural terms missing' level.

5 / 5

Distinctiveness Conflict Risk

The niche is clear and repo-specific — changeset-driven npm package publishing — with distinct trigger phrases ('changeset', 'changelog entry', 'versioning or releasing'), so it is unlikely to trigger for the wrong skill; no overlap with broader publishing or documentation skills rises above minimal.

5 / 5

Total

20

/

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.

Validation — 15 / 16 Passed

Validation for skill structure

CriteriaDescriptionResult

relative_links

Relative link issues: 1 suspicious

Warning

Total

15

/

16

Passed

Repository

hashintel/hash

Path

.agents/skills/publishing-packages/SKILL.md

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.