Execute generates conventional commit messages using AI. It analyzes code changes and suggests a commit message adhering to the conventional commits specification. Use this skill when you need help writing clear, standardized commit messages, especially a... Use when managing version control. Trigger with phrases like 'commit', 'branch', or 'git'.
40
41%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./plugins/packages/devops-automation-pack/skills/generating-conventional-commits/SKILL.mdQuality
Discovery
82%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 does a reasonable job of explaining its purpose (generating conventional commit messages) and includes explicit trigger guidance. However, it appears truncated ('especially a...'), which hurts specificity, and some trigger terms like 'branch' are overly broad and could cause conflicts with other git-related skills.
Suggestions
Fix the truncated text ('especially a...') to complete the description and add more specific actions like 'formats messages with type/scope/description structure'.
Narrow the trigger terms to focus on commit-message-specific phrases rather than broad git terms like 'branch' — consider 'commit message', 'conventional commits', 'staged changes', 'git diff'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | It names the domain (conventional commit messages) and some actions (analyzes code changes, suggests a commit message), but the description is truncated ('especially a...') and doesn't list multiple concrete actions comprehensively. | 2 / 3 |
Completeness | Clearly answers both 'what' (generates conventional commit messages by analyzing code changes) and 'when' (explicit 'Use when managing version control. Trigger with phrases like commit, branch, or git'). | 3 / 3 |
Trigger Term Quality | Includes natural keywords users would say: 'commit', 'branch', 'git', 'commit messages', 'version control'. These are terms users would naturally use when needing this skill. | 3 / 3 |
Distinctiveness Conflict Risk | The trigger terms 'branch' and 'git' are quite broad and could overlap with other git-related skills (e.g., branching strategies, merge conflict resolution). The core focus on conventional commit messages is distinct, but the broad triggers increase conflict risk. | 2 / 3 |
Total | 10 / 12 Passed |
Implementation
0%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is almost entirely boilerplate with no actionable content. It explains what conventional commits are and describes at a high level what the skill should do, but provides zero implementation details—no git commands, no code for analyzing diffs, no prompt templates, no concrete workflow. Multiple sections ('Prerequisites', 'Instructions', 'Output', 'Error Handling', 'Resources') are generic placeholders that could apply to any skill.
Suggestions
Replace the abstract 'How It Works' section with concrete executable steps: e.g., run `git diff --staged`, parse the output, map changes to conventional commit types, and format the message.
Add a concrete code example or command sequence that actually generates a commit message from staged changes, including the specific prompt or logic used to determine the commit type prefix.
Remove all generic boilerplate sections (Prerequisites, Instructions, Output, Error Handling, Resources) that provide no skill-specific information.
Include a reference table mapping change patterns to conventional commit types (feat, fix, refactor, docs, chore, etc.) with concrete heuristics for selecting the right one.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose with extensive padding. Sections like 'Overview', 'When to Use This Skill', 'Best Practices', 'Integration', 'Prerequisites', 'Instructions', 'Output', 'Error Handling', and 'Resources' are all filler that explain obvious concepts or provide vague platitudes. Claude doesn't need to be told what a commit message is or that it should 'review the generated output'. | 1 / 3 |
Actionability | No executable code, no concrete commands (not even `git diff --staged`), no actual implementation details. The 'Instructions' section is completely generic ('Invoke this skill when the trigger conditions are met'). The examples show desired outputs but not how to actually analyze changes or construct the message. | 1 / 3 |
Workflow Clarity | The 'How It Works' section describes an abstract 3-step process ('Analyze Changes', 'Generate Suggestion', 'Present to User') with no concrete implementation steps, no commands, and no validation checkpoints. The 'Instructions' section is equally vague and generic. | 1 / 3 |
Progressive Disclosure | Monolithic wall of text with no bundle files and no meaningful references. All sections are inline despite most being filler. The 'Resources' section mentions 'Project documentation' and 'Related skills and commands' without any actual links or paths. | 1 / 3 |
Total | 4 / 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 | |
69c73e9
Table of Contents
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.