release-maintainer

Internal maintainer SOP for version bumps, release PRs, tagging, publishing, and post-publish verification in this repository.

Quality

—

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Passed

No known issues

Quality

Content

70%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

An impressively lean, well-organized wrapper that avoids duplicating the canonical process, but it delegates the actual executable workflow to an external doc, leaving actionability and the main workflow's validation checkpoints somewhat implicit.

Suggestions

Inline the critical validation checkpoint between merge and tag (e.g. an explicit 'verify CI conclusion == success before tagging') rather than deferring all steps to the external doc.

Add one concrete, complete command sequence for the core release step (version bump + tag + publish) so the skill is usable without opening docs/RELEASE-PROCESS.md.

Make the external reference navigation explicit with a short 'Step-by-step process: see docs/RELEASE-PROCESS.md §<section>' pointer per phase so each execution phase is clearly signaled.

Dimension	Reasoning	Score
Conciseness	Lean throughout — it deliberately avoids duplicating the release recipe ('not as a second copy') and keeps every line to guardrails, preflight commands, and failure reminders; no concept explanations Claude already knows.	3 / 3
Actionability	It gives a few executable commands (e.g. 'gh api graphql -f query=...', 'gh run view ... --json status,conclusion,jobs', 'mise run ci') but most guidance delegates to docs/RELEASE-PROCESS.md ('Follow the ... steps in'), leaving the core workflow steps abstract rather than copy-paste ready.	2 / 3
Workflow Clarity	The preflight is numbered and the failure-recovery section gives corrective sequences, but the main execution flow is a delegate-to-docs checklist without explicit validation checkpoints between steps; the destructive/batch release operations warrant clearer feedback loops.	2 / 3
Progressive Disclosure	It correctly defers detail to a one-level-deep external doc (docs/RELEASE-PROCESS.md) and has clean sections, but the body itself is a thin wrapper whose substantive steps live entirely off-skill, so it leans on delegation rather than well-signaled in-bundle references (no references/ or scripts/ exist).	2 / 3
	Total	9 / 12 Passed

Description

65%

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 specific and well-scoped to a distinct niche, but it omits an explicit 'Use when...' trigger clause and relies on maintainer jargon rather than natural user request terms.

Suggestions

Add an explicit 'Use when...' clause naming the natural user requests that should trigger this skill (e.g. 'Use when asked to cut a release, bump the version, or publish the package').

Soften maintainer jargon like 'SOP' and 'post-publish verification' with plain request terms users would actually say, such as 'release', 'publish', and 'version bump'.

Dimension	Reasoning	Score
Specificity	Names multiple concrete actions — 'version bumps, release PRs, tagging, publishing, and post-publish verification' — matching the score-3 anchor that lists several specific concrete actions.	3 / 3
Completeness	It clearly answers 'what' (the five release actions) but provides no explicit 'when to use' / 'Use when...' trigger clause, which the guidelines say should cap completeness at 2.	2 / 3
Trigger Term Quality	Terms like 'version bumps', 'release PRs', 'tagging', and 'publishing' are relevant but framed as maintainer jargon ('SOP', 'post-publish verification'); common user-facing variations a requester might actually say are not covered as comprehensively as the score-3 example.	2 / 3
Distinctiveness Conflict Risk	Scoped tightly to a single repo's release process ('in this repository', 'maintainer SOP'), giving it a clear niche unlikely to conflict with other general-purpose skills.	3 / 3
	Total	10 / 12 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
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning
relative_links	Relative link issues: 1 suspicious	Warning

	Total	14 / 16 Passed

Repository: coder/agent-tty
Commit: fae02cb

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