conventional-commits

When writing a git commit message. When task completes and changes need committing. When project uses semantic-release, commitizen, git-cliff. When choosing between feat/fix/chore/docs types. When indicating breaking changes. When generating changelogs from commit history.

Quality

71%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./plugins/conventional-commits/skills/conventional-commits/SKILL.md

Quality

Content

68%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is a highly actionable, well-organized reference with executable code and validation tooling throughout. Its weaknesses are redundancy (breaking changes covered multiple times), padding in Benefits/FAQ, and the absence of an explicit end-to-end workflow sequence and of bundle files to offload detail.

Suggestions

Consolidate the breaking-change material into a single section to remove the triple coverage across Specification Rules, Breaking Changes, and the examples catalog.

Trim the Benefits section and FAQ entries that restate widely-known information (case sensitivity, merge-commit handling) to recover token budget.

Move the large example catalog and/or full 16-rule spec into a references/ bundle file and link to it from a concise overview, improving progressive disclosure for a skill of this length.

Dimension	Reasoning	Score
Conciseness	The core reference material (structure, types, spec rules, regex, examples) is efficient and valuable, but breaking changes are covered redundantly across three sections and the Benefits/FAQ sections include explanation and padding Claude largely already knows.	3 / 5
Actionability	The body provides fully executable, copy-paste-ready guidance: a complete validation regex, working Python validate_header/parse_header functions, commitlint install/config/test commands, and semantic-release/git-cliff configs covering the common cases.	5 / 5
Workflow Clarity	Validation mechanisms exist (regex, commitlint, parse_header) and a recovery path appears in the FAQ, but the skill is organized as a reference manual rather than a sequenced procedural workflow with explicit checkpoints.	3 / 5
Progressive Disclosure	Section headers are clear and navigation to sibling skills is well signaled via Skill() calls, but for a ~525-line skill with no bundle files, bulk reference content (full spec rules, large example catalog, FAQ) is inlined rather than split into separate files.	4 / 5
	Total	15 / 20 Passed

Description

75%Weight 40%Scale 1-5

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 provides strong, specific trigger guidance with concrete tool and type names, giving it a clear niche. Its main weakness is the absence of an explicit declarative "what this does" statement, with the capability only implied through the "When..." clauses.

Suggestions

Lead with a concise declarative capability statement (e.g., "Compose git commit messages following the Conventional Commits specification") before the trigger clauses so the "what" is explicit, not implied.

Add natural user synonyms like "version bump" or "semver" to broaden trigger-term coverage.

Consider a brief "Use when..." framing that consolidates the repeated "When..." clauses to reduce redundancy while preserving trigger specificity.

Dimension	Reasoning	Score
Specificity	The description names several concrete actions ("writing a git commit message", "choosing between feat/fix/chore/docs types", "indicating breaking changes", "generating changelogs from commit history"), but they are embedded in "When..." trigger clauses rather than stated as declarative capabilities, leaving a minor gap versus comprehensive coverage.	4 / 5
Completeness	Explicit and specific "when" trigger guidance is present across multiple concrete scenarios, while the "what" is implied through those triggers rather than stated declaratively, so it has both but the "what" could be more explicit.	4 / 5
Trigger Term Quality	Strong natural-term coverage including tool names ("semantic-release, commitizen, git-cliff"), commit types ("feat/fix/chore/docs"), and phrases like "breaking changes" and "changelogs", but a few natural synonyms a user might say (e.g., "version bump", "semver") are absent.	4 / 5
Distinctiveness Conflict Risk	Tool-specific triggers and commit-type names carve a clear niche around conventional/semantic commits, with only minor overlap risk against closely related git-commit skills.	4 / 5
	Total	16 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
skill_md_line_count	SKILL.md is long (525 lines); consider splitting into references/ and linking	Warning

	Total	15 / 16 Passed

Repository: Jamie-BitFlight/claude_skills
Path: plugins/conventional-commits/skills/conventional-commits/SKILL.md
Commit: c337daf

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

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.