When setting up commit message validation for a project. When project has commitlint.config.js or .commitlintrc files. When configuring CI/CD to enforce commit format. When extracting commit rules for LLM prompt generation. When debugging commit message rejection errors.
51
39%
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 ./plugins/commitlint/skills/commitlint/SKILL.mdQuality
Discovery
37%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 description is essentially a list of trigger conditions with no explanation of what the skill actually does. While it excels at providing natural trigger terms and keywords that users would mention, it completely lacks any capability statements, making it impossible for Claude to understand what actions this skill enables. The description needs a fundamental restructuring to lead with concrete actions before listing trigger scenarios.
Suggestions
Add a clear 'what' statement at the beginning describing concrete actions, e.g., 'Parses commitlint configuration files, generates compliant commit message formats, and validates commit messages against project rules.'
Restructure to follow the pattern: capabilities first, then 'Use when...' triggers, e.g., 'Parses and applies commitlint rules from config files to generate compliant commit messages. Use when setting up commit message validation, debugging rejection errors, or extracting commit rules for LLM prompts.'
Use third-person declarative voice for capability statements (e.g., 'Validates commit messages' rather than framing everything as situational triggers).
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description only lists 'when' scenarios but never describes concrete actions or capabilities. There are no verbs describing what the skill actually does (e.g., 'parses commitlint config', 'generates commit message templates'). The phrases like 'setting up', 'configuring', 'extracting', 'debugging' hint at actions but are framed as trigger conditions, not capability statements. | 1 / 3 |
Completeness | The description answers 'when' extensively but completely fails to answer 'what does this do'. There is no statement of capabilities or actions the skill performs. The rubric states a missing 'what' or 'when' should result in a low score, and here the 'what' is entirely absent. | 1 / 3 |
Trigger Term Quality | Includes strong natural keywords users would actually use: 'commitlint.config.js', '.commitlintrc', 'commit message validation', 'CI/CD', 'commit format', 'commit message rejection errors', 'LLM prompt generation'. These cover multiple variations and specific file names that would naturally appear in user queries. | 3 / 3 |
Distinctiveness Conflict Risk | The mention of specific files like 'commitlint.config.js' and '.commitlintrc' provides some distinctiveness, but without stating what the skill actually does, it could overlap with general git/CI-CD skills. The commitlint-specific terms help narrow the niche somewhat. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
42%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This skill is a comprehensive but excessively verbose commitlint reference that mirrors official documentation rather than providing a lean, actionable skill. Its strength is highly actionable code examples across multiple languages, but it's severely undermined by including exhaustive rule reference tables and configuration file listings that Claude doesn't need inline. The content would benefit enormously from splitting reference material into separate files and keeping only the essential workflow and integration patterns in the main skill.
Suggestions
Move the exhaustive rule reference tables (Type, Subject, Scope, Header, Body, Footer rules) and case values into a separate RULES_REFERENCE.md file, keeping only the most common rules inline with a pointer to the reference.
Remove the configuration detection file listing (14 filenames) and replace with a one-line note like 'Commitlint uses cosmiconfig; supports .commitlintrc.{json,yaml,js,ts}, commitlint.config.{js,ts}, or package.json commitlint field.'
Consolidate the four configuration format examples into one recommended format with a brief note about alternatives, rather than showing JS, TS, JSON, and YAML variants.
Add explicit validation checkpoints to the LLM integration validation loop with concrete error-handling code rather than a prose description of the retry pattern.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely verbose at ~400+ lines. Exhaustive rule reference tables (type, subject, scope, header, body, footer rules) are documentation Claude can look up. The config detection file listing, case values reference, complete configuration schema, and exit codes table all pad the skill with information Claude already knows or could infer. This reads like a documentation mirror, not a skill. | 1 / 3 |
Actionability | Provides fully executable code examples across JavaScript, TypeScript, Python, and CLI commands. Installation commands, validation functions, and programmatic usage are all copy-paste ready with concrete examples. | 3 / 3 |
Workflow Clarity | The LLM validation loop pattern describes steps but lacks explicit validation checkpoints and error recovery details. The 5-step validation loop is described as a list rather than with concrete implementation. The troubleshooting section covers common issues but doesn't integrate into a clear diagnostic workflow. | 2 / 3 |
Progressive Disclosure | Monolithic wall of text with no content split into separate files. The extensive rule reference tables, complete configuration schema, and CLI reference should be in separate reference files. The two cross-references to other skills at the bottom are good but insufficient given the massive inline content. | 1 / 3 |
Total | 7 / 12 Passed |
Validation
90%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 10 / 11 Passed
Validation for skill structure
| Criteria | Description | Result |
|---|---|---|
skill_md_line_count | SKILL.md is long (522 lines); consider splitting into references/ and linking | Warning |
Total | 10 / 11 Passed | |
b9f32ec
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.