create-release-note
Create a reno release note for a PR or change
72
67%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./.claude/skills/create-release-note/SKILL.mdQuality
Discovery
57%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 identifies a specific tool (reno) and a clear action (create release notes), giving it good distinctiveness. However, it is too terse—lacking multiple concrete actions, common keyword variations, and an explicit 'Use when...' clause—which limits its effectiveness for skill selection among many options.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to create a changelog entry, release note, or reno note for a pull request or code change.'
Include additional trigger terms and variations such as 'changelog', 'release notes', 'reno new', 'YAML release note', and 'version notes'.
Expand the capability description with more concrete actions, e.g., 'Generates reno YAML release note files, categorizes changes (features, bug fixes, deprecations), and places them in the correct releasenotes directory.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain ('reno release note') and a single action ('create'), but does not list multiple concrete actions or elaborate on what creating a reno release note entails (e.g., generating YAML files, categorizing changes, formatting entries). | 2 / 3 |
Completeness | It answers 'what' (create a reno release note) but lacks an explicit 'Use when...' clause or equivalent trigger guidance. The 'when' is only implied by the mention of 'for a PR or change'. | 2 / 3 |
Trigger Term Quality | Includes relevant keywords like 'reno', 'release note', 'PR', and 'change', which are terms a user might naturally use. However, it misses common variations such as 'changelog', 'release notes', 'releasenote', 'new note', or references to the reno YAML format. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of 'reno' is a very specific tool name that creates a clear niche. It is unlikely to conflict with other skills since reno is a distinct release notes management tool. | 3 / 3 |
Total | 9 / 12 Passed |
Implementation
77%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a strong, actionable skill that provides project-specific knowledge Claude genuinely needs (reno conventions, directory structure, RST formatting rules, linting commands). The workflow is well-sequenced with proper validation. Minor weaknesses include some content duplication between Step 1 and the Section Guidelines table, and the overall length could be trimmed slightly.
Suggestions
Remove the Section Guidelines table or the section descriptions in Step 1 to eliminate duplication — one location with full descriptions is sufficient.
Consider extracting the RST formatting rules into a separate reference file if the bundle supports it, keeping only a brief reminder in the main skill.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient and provides necessary project-specific information Claude wouldn't know (reno format, section types, RST rules, directory structure). However, the section guidelines table partially duplicates information already given in Step 1, and some explanations could be tightened. | 2 / 3 |
Actionability | Provides fully executable commands (`reno new <topic> --no-edit`, `dda inv linter.releasenote`), concrete YAML file format examples, specific RST formatting rules with correct/incorrect patterns, and clear examples for each section type. Copy-paste ready throughout. | 3 / 3 |
Workflow Clarity | Clear 4-step sequence (gather info → create file → format content → verify) with an explicit validation checkpoint (run linter, fix issues, re-run). The feedback loop for linting failures is explicitly stated, and the workflow handles conditional paths (APM changes, non-default directories). | 3 / 3 |
Progressive Disclosure | The content is well-structured with clear headers and logical sections, but it's a single monolithic file with some content duplication (section descriptions appear both in Step 1 and the Section Guidelines table). For a skill of this length (~100 lines of substantive content), the section guidelines table or RST formatting rules could potentially be split into referenced files, though no bundle files exist. | 2 / 3 |
Total | 10 / 12 Passed |
Validation
81%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 9 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
allowed_tools_field | 'allowed-tools' contains unusual tool name(s) | Warning |
frontmatter_unknown_keys | Unknown frontmatter key(s) found; consider removing or moving to metadata | Warning |
Total | 9 / 11 Passed | |
- Repository
- DataDog/datadog-agent
- Commit
0f36ad4
- 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.