Name: changesets
Rating: 67.2 (1 reviews)
Author: cloudflare

changesets

Use when creating a changeset, preparing a release, or bumping versions. Covers which packages to reference, how to write user-facing changeset descriptions, the release automation flow, and the npm/Docker version sync requirement. (project)

Quality

81%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

78%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 highly actionable with copy-paste-ready templates, concrete paths, and a good/bad example, and it is well-organized as a self-contained overview. The main flaw is redundancy — the package-reference rule is duplicated nearly verbatim and the Checklist restates earlier rules — which hurts token efficiency.

Suggestions

Remove the duplicated "Important: Changeset files should only reference @cloudflare/sandbox..." paragraph in Writing the Description — it restates the Rules section and the Checklist item verbatim; state the rule once.

Trim the release-orchestrator artifact lists in steps 4-5 (npm package, Docker Hub images, CF Registry images, GitHub Release, binaries, aliases) to a single summary sentence, since publishing is fully automated and Claude never executes it.

Consider merging the Rules subsection into Creating a Changeset so the file format, bump-type choice, and package rule read as one procedure rather than three scattered statements.

Dimension	Reasoning	Score
Conciseness	The body is mostly tight with no basic-concept padding, but the "only reference @cloudflare/sandbox, never @repo/shared or @repo/sandbox-container" rule is stated twice nearly verbatim (Rules section and again under Writing the Description), and the Checklist reiterates prior rules. This is noticeable duplication that could be tightened, matching anchor 3 rather than 4.	3 / 5
Actionability	Fully executable guidance: a copy-paste-ready changeset file template with exact frontmatter format, concrete paths (`.changeset/`, `.github/workflows/release.yml`, `packages/sandbox/src/version.ts`, `ARG SANDBOX_VERSION` in the Dockerfile), explicit bump-type rules, and a good/bad description example covering the common cases. Matches anchor 5.	5 / 5
Workflow Clarity	Release automation is a clear numbered 6-step sequence and the primary changeset-creation action is unambiguous, with a closing Checklist serving as validation checkpoints. Not 5 because validation relies on external "pre-commit hooks and CI" rather than any step Claude performs, and the release flow is informational for Claude.	4 / 5
Progressive Disclosure	No bundle files exist, and the self-contained body needs none: all content is appropriately inline at overview level, organized under clear section headers (Creating a Changeset, Rules, Writing the Description, Release Automation, Version Synchronization, Checklist) with easy navigation and no nested references.	5 / 5
	Total	17 / 20 Passed

Description

83%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: it explicitly states both what the skill covers and when to use it, with concrete trigger phrases (changeset, release, bump versions) and specific capability items. The only weaknesses are a few missing natural synonyms (publish, changelog) and minor overlap risk with generic release tooling.

Dimension	Reasoning	Score
Specificity	"creating a changeset, preparing a release, or bumping versions" plus the itemized coverage ("which packages to reference, how to write user-facing changeset descriptions, the release automation flow, and the npm/Docker version sync requirement") lists several specific capabilities. Below anchor 5 because coverage is topical with minor gaps (e.g., changelog handling, publishing commands) rather than comprehensive concrete actions.	4 / 5
Completeness	"Use when creating a changeset, preparing a release, or bumping versions" explicitly answers when with concrete trigger phrases, and "Covers which packages to reference, how to write user-facing changeset descriptions, the release automation flow, and the npm/Docker version sync requirement" explicitly answers what. Clearly matches the anchor 5 example structure.	5 / 5
Trigger Term Quality	"changeset", "release", "bumping versions", "npm", "Docker" are natural terms a user would say. Not 5 because common variations like "publish", "changelog", or "Version Packages" are missing.	4 / 5
Distinctiveness Conflict Risk	The repo-specific changeset workflow (marked "(project)") is a distinct niche, but "preparing a release" and "bumping versions" carry minor overlap risk with a generic publish/release skill. Fits anchor 4 ("mostly distinct; minor overlap risk") better than 5.	4 / 5
	Total	17 / 20 Passed

Validation

100%

Warnings & errors only

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: cloudflare/sandbox-sdk
Path: .agents/skills/changesets/SKILL.md
Commit: 831b8c5

Reviewed: 7 days ago

Table of Contents

Discovery Implementation Validation

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.