promote-beta

Compatibility entrypoint for beta promotion. Prefer release-lanes for end-to-end latest/beta lane maintenance.

Quality

58%

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/promote-beta/SKILL.md

Quality

Content

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

This is an appropriately minimal compatibility shim: it explains its purpose in one line, routes to the owning skill unambiguously, and provides genuinely useful copy-paste commands for the common cases. The main weaknesses are the absence of post-execution verification steps for push/promote operations and a paragraph of now-irrelevant workflow history.

Suggestions

Add a short verification step after the dry-run/push commands, e.g. 'Check run status: `gh run watch` / confirm the npm dist-tag with `npm view <pkg> dist-tags` before considering the lane done' — this would lift workflow clarity above the destructive/batch cap.

Trim the historical paragraph ('The old split was too manual...') to one line or move it into a small 'Deprecated' note, since a routing shim needs only the redirect and the current owner's scope.

Briefly note what the referenced scripts are and where they live (or inline the essential flags), since none of the referenced paths are part of this skill's bundle and a reader outside the repo cannot resolve them.

Dimension	Reasoning	Score
Conciseness	The body is short (~40 lines) and mostly lean: a one-line purpose statement, a routing instruction, and three copy-paste commands with no filler or concept explanations. It is not 5 because the historical paragraph ('The old split was too manual: promote PR, generated sync PR, then beta re-entry...') explains deprecated workflow history that a routing shim does not need and could be trimmed to a sentence.	4 / 5
Actionability	The guidance is concrete and executable: a full `create-goal-scratchpad.mjs` invocation with template and title flags, a complete `gh workflow run promote.yml` command, and both the `--dry-run` and `--push` forms of the sync script. It is not 5 because the primary routing instruction points at `.agents/rules/release-lanes.mdc` and the scripts at repo paths that are not part of this skill's bundle (no references/ or scripts/ directories exist), so a reader cannot verify or execute them from the skill alone; no argument values (repo, PR URL, version) are explained either.	4 / 5
Workflow Clarity	The skill offers dry-run variants of both the promote workflow and the main-to-next sync before the real `--push`, which shows some checkpoint awareness, but there are no post-run verification steps (watching the run, npm readback, PR confirmation) and no error-recovery guidance, and the quick commands are presented as an unordered list rather than a sequence. Since the operations include real pushes and workflow triggers (batch/destructive-adjacent), the missing validation steps cap this at 3 per the rubric guidelines. Not 2 because dry-run-then-push does provide an implicit validate-then-execute pattern and the routing instruction is unambiguous.	3 / 5
Progressive Disclosure	The body is well-organized into clear sections (title/purpose, Route, Quick Commands), keeps the SKILL.md as an overview, and delegates all end-to-end detail to the release-lanes skill via one clearly signaled one-level-deep reference. It is not 5 because the referenced paths (release-lanes.mdc, create-goal-scratchpad.mjs, release-branch-prs.mjs) live outside the skill bundle and cannot be navigated from it — the Quick Commands assume repo context that the skill itself does not provide.	4 / 5
	Total	15 / 20 Passed

Description

48%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 is concise and honest about being a compatibility shim, with a clear hand-off to release-lanes, but it functions more as a deprecation notice than a capability description: it lists no concrete actions and has no 'Use when' trigger guidance. Users would likely find it via the term 'beta promotion', which is the only strong trigger present.

Suggestions

Add an explicit trigger clause, e.g. 'Use when the user asks to promote the beta channel, promote a release to latest, or when an older prompt mentions promote-beta.'

Name 1-2 concrete capabilities instead of only routing language, e.g. 'Runs promote dry runs via the promote.yml workflow and syncs main -> next' alongside the release-lanes pointer.

Include common synonyms such as 'promote beta', 'release to latest', and 'main to next sync' so the description matches how users actually phrase the request.

Dimension	Reasoning	Score
Specificity	The description names the domain ("beta promotion", "latest/beta lane maintenance") but states no concrete actions — it only says it is a "Compatibility entrypoint" and to "Prefer release-lanes", with no verbs describing what it actually does. This matches the anchor 'Names the domain but actions are minimal or generic'. It is below score 3 because no concrete action (promote, sync, publish) is listed, and above score 1 because the domain is named specifically.	2 / 5
Completeness	The 'what' is reasonably clear (a compatibility entrypoint that routes to release-lanes for beta/latest maintenance), but there is no 'Use when...' clause or equivalent trigger guidance, so per the judging guidelines completeness is capped at 3. Not 4 because 'when' is entirely absent rather than just imprecise.	3 / 5
Trigger Term Quality	"beta promotion" and "latest/beta" are relevant natural terms a user might say, but common variations are missing (e.g., "promote beta", "cut a release", "publish to npm", "sync main to next"). This fits 'Some relevant keywords but missing common variations or synonyms'; not 4 because the keyword set is thin, and not 2 because the terms present are specific rather than generic.	3 / 5
Distinctiveness Conflict Risk	The trigger domain (beta promotion / release lanes) is specific and the description explicitly distinguishes it from the sibling skill ("Prefer release-lanes for end-to-end latest/beta lane maintenance"), giving it a mostly distinct niche with only minor overlap risk with release-lanes itself. Not 5 because the phrase "lane maintenance" could bleed into release-lanes' territory without the routing sentence being read.	4 / 5
	Total	12 / 20 Passed

Validation

81%

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 — 13 / 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
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	13 / 16 Passed

Repository: udecode/plate
Path: .agents/skills/promote-beta/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.