CtrlK
BlogDocsLog inGet started
Tessl Logo

create-release-note

Create a reno release note for a PR or change

57

Quality

67%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./.claude/skills/create-release-note/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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 well-crafted skill that provides clear, actionable guidance for creating reno release notes with project-specific conventions Claude wouldn't know. Its strengths are the concrete commands, explicit validation step, and clear workflow sequencing. The main weakness is some redundancy between the section descriptions in Step 1 and the Section Guidelines table, which inflates token usage without adding significant value.

Suggestions

Remove the Section Guidelines table or the section descriptions in Step 1 — they largely duplicate each other. Keep whichever is more concise (the table) and reference it from Step 1.

Consider extracting the RST formatting rules and section guidelines into a bundle reference file to reduce the main skill's token footprint.

DimensionReasoningScore

Conciseness

The skill is mostly efficient and provides necessary project-specific information Claude wouldn't know (reno format, section types, RST rules, directory targets). However, the section guidelines table largely 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 examples, and clear usage patterns. The guidance is copy-paste ready and specific.

3 / 3

Workflow Clarity

Clear 4-step sequence from gathering information through creation to verification. Includes an explicit validation step (Step 4) with the linter command, specifies what the linter checks, and implies a fix-and-rerun feedback loop. The workflow handles conditional paths (APM changes, non-default directories) clearly.

3 / 3

Progressive Disclosure

The content is well-structured with clear sections and headers, but it's somewhat long for a single file with no bundle files to offload detail into. The section guidelines table and the 'when to skip' section could potentially be separate references. However, for a skill of this complexity without bundle files, the inline organization is reasonable.

2 / 3

Total

10

/

12

Passed

Description

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 is concise and identifies a specific tool (reno) which gives it good distinctiveness, but it is too terse to fully serve its purpose. It lacks an explicit 'Use when...' clause and does not enumerate the concrete actions involved in creating a reno release note, limiting both completeness and specificity.

Suggestions

Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to create a release note, changelog entry, or reno note for a pull request or code change.'

Expand the capability description with more concrete actions, e.g., 'Generates reno YAML release note files, categorizes changes (features, bug fixes, deprecations), and formats entries following reno conventions.'

Include additional trigger term variations such as 'changelog', 'version notes', 'release notes', and 'reno new' to improve keyword coverage.

DimensionReasoningScore

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', 'reno new', or 'version notes'.

2 / 3

Distinctiveness Conflict Risk

The mention of 'reno' is quite specific and refers to a particular release notes tool (OpenStack's reno), making it clearly distinguishable from generic documentation or changelog skills.

3 / 3

Total

9

/

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.

Validation9 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

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