stave-release

Release workflow for the Stave repository that confirms whether the next release is patch or minor before bumping the version, reviews the actual PR changes and PR description `Changes` sections in the release scope instead of relying on commit titles alone, generates release notes with `conventional-changelog`, and opens a pull request against `main` from a dedicated temporary release worktree so the user's original checkout stays on its original branch. Use when the user asks to cut the next release, ship the current changes as a versioned release, or prepare a release PR. After the PR merges, the repository's GitHub Actions workflow builds and publishes the release artifacts automatically.

Quality

90%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Low

Low-risk findings worth noting

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.

A highly actionable, well-sequenced release workflow with strong validation and feedback loops. The main weakness is redundancy: the Guardrails section duplicates step-level rules and the body overlaps the referenced checklist.

Suggestions

Trim the Guardrails section to only rules not already stated in the workflow steps, or replace it with a one-line pointer to the steps, to remove redundancy.

Split responsibilities more sharply between SKILL.md and stave-release-checklist.md so the body is a concise overview and the checklist holds the exact sequence, reducing overlap.

Dimension	Reasoning	Score
Conciseness	Dense and actionable with no explanation of concepts Claude already knows, but the Guardrails section restates several rules already embedded in the workflow steps (e.g., 'Never push directly to main', 'Never hardcode a repository path'), which could be trimmed.	4 / 5
Actionability	Provides fully executable, copy-paste-ready commands throughout — `git rev-parse --show-toplevel`, `git tag --list 'v*' --sort=-version:refname \| head -5`, `bunx --bun conventional-changelog-cli -p conventionalcommits -i CHANGELOG.md -s`, `gh pr view <number> --json title,body,files,url` — covering the common cases with clear placeholders.	5 / 5
Workflow Clarity	Ten clearly numbered steps with explicit validation checkpoints (step 2 prior-tag check, step 6 typecheck/tests, step 8 post-open PR diff review) and stop-and-surface feedback loops for risky outcomes (missing tag, unrelated changes, verification failure, dirty worktree).	5 / 5
Progressive Disclosure	Points to a real one-level-deep reference (`references/stave-release-checklist.md`) for the exact sequence, but the SKILL.md body itself contains a full release sequence that substantially overlaps the referenced checklist, leaving a minor organization gap.	4 / 5
	Total	18 / 20 Passed

Description

92%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, third-person description that concretely states what the skill does and gives explicit natural-language triggers for when to use it. Only minor weakness is a few missing trigger synonyms.

Suggestions

Add 'publish', 'tag', or 'bump the version' to the 'Use when...' clause to broaden trigger coverage for users who phrase the request differently.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions — 'confirms whether the next release is patch or minor before bumping the version', 'reviews the actual PR changes and PR description Changes sections', 'generates release notes with conventional-changelog', 'opens a pull request against main from a dedicated temporary release worktree' — giving comprehensive coverage of the release workflow.	5 / 5
Completeness	Explicitly answers both what (the four-part release workflow) and when ('Use when the user asks to cut the next release, ship the current changes as a versioned release, or prepare a release PR') with concrete trigger phrases.	5 / 5
Trigger Term Quality	Includes natural trigger phrasings users would say — 'cut the next release', 'ship the current changes as a versioned release', 'prepare a release PR' — but misses common variations such as 'publish a release', 'tag a release', or 'bump the version' as explicit triggers.	4 / 5
Distinctiveness Conflict Risk	Scoped specifically to the Stave repository with a distinct release-PR niche (worktree-based, conventional-changelog), making conflict with other skills minimal.	5 / 5
	Total	19 / 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: sendbird/stave
Path: skills/stave-release/SKILL.md
Commit: 69ca766

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.