update-version

Update `AvailableFrom` in a PR to the next Remotion patch version (`main` + `0.0.1`).

Quality

71%

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/update-version/SKILL.md

Quality

Content

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

An efficient, highly actionable body: two exact git commands, an explicit version-computation rule with a worked example, and a precise constraint against touching unrelated values. The main gap is the absence of any post-edit verification step for what is a batch change followed by commit and push.

Suggestions

Add a verification step after the edits, e.g. re-run `git --no-pager diff origin/main...HEAD -- packages/docs | rg 'AvailableFrom v="'` and confirm every PR-touched value now equals the computed version before committing.

Make step 5 concrete by specifying the commit scope or message convention (e.g. what the commit should reference) and that the push targets the PR's branch.

Optionally show the version arithmetic as an explicit example pair (`4.0.468` → `4.0.469`) — already present — and note what to do if the PR contains no `AvailableFrom` changes (no-op exit).

Dimension	Reasoning	Score
Conciseness	The body is lean: a one-line trigger statement, five numbered steps, two copy-paste git commands, and a single worked example ("for example: `4.0.468`") that earns its tokens. No concepts Claude already knows are explained, matching the score-5 anchor "every token earns its place".	5 / 5
Actionability	The fetch/show/diff commands are executable and copy-paste ready, and the patch-increment rule is concrete. It is not 5 because steps 3 and 5 ("Update only `AvailableFrom` values...", "Commit and push the update") give direction without a concrete edit command or commit-message convention — minor gaps matching the score-4 anchor.	4 / 5
Workflow Clarity	The five steps are clearly sequenced with a correct diff base (`origin/main...HEAD`), but the workflow performs a batch edit plus commit-and-push with no verification checkpoint (e.g., re-running the diff to confirm every PR-touched `AvailableFrom` matches the computed version). The guideline "missing validation in batch/destructive operations caps workflow clarity at 3" applies; not 4 because validation is absent, not just minor.	3 / 5
Progressive Disclosure	This is a simple single-purpose skill under 50 lines with no need for external references, and no bundle files exist. The numbered-step organization is clean and self-contained, satisfying the guideline that such skills can score 5 with just well-organized sections.	5 / 5
	Total	17 / 20 Passed

Description

62%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 specific, honest description of a single well-defined action with excellent distinctiveness, but it omits any "when to use" trigger guidance and lacks natural trigger variations like "bump version". Moving the body's "Use this when a PR contains docs changes with `<AvailableFrom v=...>`" trigger into the description would resolve both weaknesses.

Suggestions

Add an explicit 'Use when...' clause to the description, e.g. "Use when a PR changes docs containing `<AvailableFrom v="...">` and the value should reflect the next release."

Include natural trigger synonyms such as "bump version", "next release version", or "Remotion docs" so users' phrasing matches the description.

Keep the version-arithmetic parenthetical (`main` + `0.0.1`) — it is concrete and differentiating — while appending the trigger clause rather than lengthening the capability statement.

Dimension	Reasoning	Score
Specificity	The description states a concrete action — "Update `AvailableFrom` in a PR to the next Remotion patch version (`main` + `0.0.1`)" — naming the exact field, artifact, and version arithmetic. It stays at 4 rather than 5 because only a single action is covered; score 5 anchors require multiple specific concrete actions.	4 / 5
Completeness	The "what" is clear (update AvailableFrom values to the computed next patch version), but there is no "Use when..." clause or equivalent trigger guidance in the description — the trigger lives only in the body. Per the judging guidelines, a missing 'Use when' clause caps completeness at 3; not 4 because the when is entirely absent rather than merely improvable.	3 / 5
Trigger Term Quality	Relevant keywords exist ("Update", "PR", "version", "Remotion", "patch", "AvailableFrom") but common natural phrasings a user would actually say — "bump version", "release version", "version bump" — are missing. Not 4 because the coverage lacks natural synonyms; not 2 because the terms present are domain-relevant rather than generic.	3 / 5
Distinctiveness Conflict Risk	"AvailableFrom" and "Remotion" are highly distinctive trigger tokens confined to a narrow niche, making it unlikely to fire for unrelated versioning or docs skills. Score 4 would require some overlap risk with closely related skills, which is not present here.	5 / 5
	Total	15 / 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: remotion-dev/remotion
Path: .agents/skills/update-version/SKILL.md
Commit: 6f4e0d5

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