registry-changelog

Author and verify Plate registry changelog entries for user-visible registry UI, kit, example, and registry metadata changes.

Quality

73%

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

Fix and improve this skill with Tessl

tessl review fix ./.agents/skills/registry-changelog/SKILL.md

Quality

Content

88%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 tight, highly actionable contract with executable commands, a complete MDX example, and a closeout checklist containing explicit validation checkpoints. Its only weaknesses are minor redundancy between the opening and 'When Required' sections and a monolithic single-file structure that is slightly long for a skill with no reference files.

Dimension	Reasoning	Score
Conciseness	The body is dense, imperative, and contract-specific with no explanations of concepts Claude already knows, but there is minor redundancy — the opening paragraph and 'When Required' both enumerate the user-visible registry scope. This matches 'efficient with minor instances that could be trimmed' rather than the every-token-earns-its-place level 5.	4 / 5
Actionability	Four copy-paste-ready bash commands (--new, --write, --check, focused tests), a complete MDX example with exact frontmatter values like '{"type":"source","date":"YYYY-MM-DD","commits":[]}', and a full field-contract table make the guidance fully executable and cover the common cases.	5 / 5
Workflow Clarity	The workflow is clearly sequenced — create the source entry, regenerate with --write, verify with --check, run focused tests when the generator changed — and the Closeout checklist provides explicit validation checkpoints including '--check passes'. The destructive/batch cap does not apply because validation steps are present.	5 / 5
Progressive Disclosure	The body is well-organized into clear sections with appropriate inline content for a single-contract skill, but at roughly 130 lines it exceeds the simple-skill threshold and the full frontmatter contract table plus MDX example could plausibly live in a reference file. This matches 'good structure with minor organization gaps' rather than a well-signaled multi-file split.	4 / 5
	Total	18 / 20 Passed

Description

57%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 states a clear, specific "what" in a distinct niche with concrete registry-scope terms, but it omits any explicit "when to use" trigger clause and lacks natural trigger synonyms. It is serviceable but reads more like a scope definition than an invocation trigger.

Suggestions

Append a 'Use when...' clause naming the trigger conditions, e.g. 'Use when a task changes user-visible registry UI components, kits, examples, or registry metadata under apps/www/src/registry/**'.

Add natural trigger synonyms users would actually say — 'changelog entry', 'changeset', 'release notes' — alongside the current technical terms 'Plate registry' and 'kit'.

Broaden the action verbs beyond 'author and verify' to include 'regenerate and check generated changelog JSON' so the capability coverage matches what the skill body actually instructs.

Dimension	Reasoning	Score
Specificity	"Author and verify ... changelog entries" names the domain and exactly two concrete actions, with scope items (registry UI, kit, example, metadata) enumerated. Only two verbs are listed rather than the several specific actions the level-4 anchor requires, but the language is concrete rather than generic, so it sits above level 2.	3 / 5
Completeness	The description clearly answers "what" (author and verify Plate registry changelog entries) but contains no "Use when..." clause or equivalent explicit trigger guidance; the trailing "for user-visible registry UI, kit, example, and registry metadata changes" only weakly implies when. Per the judging guidelines, a missing 'Use when' clause caps completeness at 3.	3 / 5
Trigger Term Quality	Relevant keywords are present ("changelog", "registry", "Plate", "kit", "example", "metadata") but they lean technical and miss natural variations users would say, such as "changeset", "release notes", or a plain "Use when..." phrase. This matches the anchor for some relevant keywords with missing synonyms rather than good coverage.	3 / 5
Distinctiveness Conflict Risk	"Plate registry changelog entries" with the enumerated registry scope (UI, kit, example, registry metadata) carves out a clear niche with distinct triggers and minimal conflict risk with other skills. Level 4 would require noticeable overlap with closely related skills, which is not the case here.	5 / 5
	Total	14 / 20 Passed

Validation

87%

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 — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
metadata_version	'metadata.version' is missing	Warning
metadata_field	'metadata' should map string keys to string values	Warning

	Total	14 / 16 Passed

Repository: udecode/plate
Path: .agents/skills/registry-changelog/SKILL.md
Commit: babb3c2

Reviewed: 2 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.