CtrlK
BlogDocsLog inGet started
Tessl Logo

commitlint

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

Quality

39%

Does it follow best practices?

Impact

Pending

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./plugins/commitlint/skills/commitlint/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

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

DimensionReasoningScore

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.

DimensionReasoningScore

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.

Validation10 / 11 Passed

Validation for skill structure

CriteriaDescriptionResult

skill_md_line_count

SKILL.md is long (522 lines); consider splitting into references/ and linking

Warning

Total

10

/

11

Passed

Repository
Jamie-BitFlight/claude_skills
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.