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.
68
81%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Advisory
Suggest reviewing before use
Quality
Discovery
100%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is an excellent skill description that thoroughly covers what the skill does with multiple concrete actions, provides explicit trigger guidance via a 'Use when...' clause with natural language variations, and is highly distinctive due to its repository-specific and workflow-specific scope. The description is detailed without being padded, and uses proper third-person voice throughout.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description lists multiple specific concrete actions: confirming patch vs minor version, reviewing PR changes and description sections, generating release notes with conventional-changelog, opening a PR against main from a dedicated temporary release worktree, and preserving the user's original branch checkout. | 3 / 3 |
Completeness | Clearly answers both 'what does this do' (the detailed release workflow steps) AND 'when should Claude use it' with an explicit 'Use when...' clause listing three trigger scenarios. Also includes post-merge context about automated publishing. | 3 / 3 |
Trigger Term Quality | Includes natural trigger terms users would say: 'cut the next release', 'ship the current changes as a versioned release', 'prepare a release PR'. Also includes domain-specific but recognizable terms like 'release notes', 'version bump', 'release workflow', and the repository name 'Stave'. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive — scoped to a specific repository (Stave), a specific workflow (release), with specific tooling (conventional-changelog, temporary release worktree). Very unlikely to conflict with other skills due to the narrow, well-defined niche. | 3 / 3 |
Total | 12 / 12 Passed |
Implementation
62%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill is highly actionable with excellent workflow clarity, providing concrete commands, validation checkpoints, and error recovery paths for a complex multi-step release process. However, it is significantly over-verbose—the guardrails section largely duplicates workflow constraints, and many instructions over-explain operations Claude can handle with briefer guidance. The content would benefit from moving detailed procedures into the referenced checklist file and keeping SKILL.md as a concise overview.
Suggestions
Move the detailed step-by-step instructions (especially steps 4, 7, 8, 9) into `references/stave-release-checklist.md` and keep SKILL.md as a concise overview with key decision points and guardrails only.
Eliminate redundancy between the Workflow steps and Guardrails section—each constraint should appear in exactly one place, preferably as inline notes within the relevant workflow step.
Remove explanations of things Claude already knows (e.g., how semver incrementing works, what `git stash` does) and trust Claude to execute standard git/gh operations from brief instructions.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose at ~150+ lines with significant redundancy. Many guardrails repeat workflow steps verbatim (e.g., 'Never push directly to main' appears twice, worktree cleanup rules are stated in both workflow and guardrails). The level of detail on git worktree management, stash handling, and changelog reconciliation is excessive given Claude's competence with these tools. | 1 / 3 |
Actionability | The skill provides fully concrete, executable commands throughout (git, gh, bunx, bun run typecheck). Every step includes specific CLI invocations, exact commit message formats, branch naming conventions, and PR body requirements. The guidance is copy-paste ready. | 3 / 3 |
Workflow Clarity | The 10-step workflow is clearly sequenced with explicit validation checkpoints (step 2 inspects state, step 6 runs typecheck/tests, step 8 reviews the PR diff post-creation, step 9 verifies original branch). Error recovery is addressed (stop on unexpected changes, handle dirty worktrees, retry worktree removal). Feedback loops are present for destructive/batch operations. | 3 / 3 |
Progressive Disclosure | The skill references `references/stave-release-checklist.md` at the top for the 'exact sequence and repair rules,' which is good progressive disclosure. However, no bundle files are provided to verify this reference exists, and the SKILL.md itself contains an enormous amount of inline detail that could be split into the referenced checklist, making the main file a monolithic wall of instructions. | 2 / 3 |
Total | 9 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- sendbird/stave
- Commit
e275ad5
- Reviewed
Table of Contents
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.