commit
Create well-formatted commits with conventional commit messages and emoji
42
30%
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/git/skills/commit/SKILL.mdQuality
Discovery
32%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 conveys the core purpose—creating conventional commit messages with emoji—but lacks a 'Use when...' clause, which is critical for skill selection. It also misses common trigger terms users would naturally use and doesn't list enough concrete actions to fully distinguish itself from other git-related skills.
Suggestions
Add an explicit 'Use when...' clause, e.g., 'Use when the user asks to commit changes, write a commit message, or mentions git commits, staged changes, or conventional commits.'
Include more natural trigger terms and variations such as 'git commit', 'commit message', 'gitmoji', 'staged changes', and 'changelog'.
List additional concrete actions if applicable, such as 'analyzes staged diffs, generates conventional commit prefixes (feat, fix, chore), and appends relevant emoji'.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (commits) and some actions (create, format), but doesn't list multiple concrete actions beyond creating commits with conventional messages and emoji. It's somewhat specific but not comprehensive. | 2 / 3 |
Completeness | Describes what the skill does but completely lacks a 'Use when...' clause or any explicit trigger guidance for when Claude should select this skill. Per the rubric, a missing 'Use when...' clause caps completeness at 2, and since the 'what' is also only moderately detailed, this scores a 1. | 1 / 3 |
Trigger Term Quality | Includes relevant keywords like 'commits', 'conventional commit messages', and 'emoji', but misses common variations users might say such as 'git commit', 'commit message', 'staged changes', 'gitmoji', or 'changelog'. | 2 / 3 |
Distinctiveness Conflict Risk | The mention of 'conventional commit messages and emoji' provides some distinctiveness, but it could overlap with general git workflow skills or code review skills. Adding explicit triggers would help differentiate it further. | 2 / 3 |
Total | 7 / 12 Passed |
Implementation
27%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
The skill provides a comprehensive but excessively verbose guide to creating conventional commits with emoji. Its main weakness is extreme bloat—the emoji mapping table alone accounts for a huge portion of the content and could be a separate reference file. The workflow is reasonably clear but lacks concrete executable commands and validation checkpoints.
Suggestions
Move the emoji/commit-type mapping table to a separate reference file (e.g., EMOJI_REFERENCE.md) and link to it from the main skill, drastically reducing token usage.
Remove explanations of concepts Claude already knows (conventional commit format basics, what imperative mood means, what different commit types represent).
Add concrete executable git commands for the split-commit workflow (e.g., specific `git add -p`, `git reset HEAD`, `git commit -m` examples).
Add an explicit validation checkpoint after committing (e.g., 'Run `git log --oneline -1` to verify the commit message matches expectations').
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is extremely verbose with a massive emoji/commit-type mapping table (60+ entries), redundant examples that restate the table, and explanations of concepts Claude already knows (what conventional commits are, what present tense imperative mood means). The content could be cut by 60%+ without losing actionable information. | 1 / 3 |
Actionability | The workflow steps are reasonably concrete (git status, git diff, git add), but there are no actual executable commands or code snippets for the core operations—just descriptions of what to do. The branch naming and commit message format are well-specified, but the pre-commit check step is vague ('pnpm lint or similar depending on the project language'). | 2 / 3 |
Workflow Clarity | The numbered steps in the Instructions section provide a clear sequence, and there's mention of checking for pre-commit failures and asking the user. However, there are no explicit validation checkpoints after committing, no feedback loop for verifying the commit was correct, and the split-commit workflow lacks concrete staging/unstaging steps. | 2 / 3 |
Progressive Disclosure | The entire skill is a monolithic wall of text with no references to external files. The massive emoji table, splitting guidelines, examples, branch naming conventions, and command options are all inlined when much of this (especially the emoji mapping) should be in a separate reference file. | 1 / 3 |
Total | 6 / 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 | |
- Repository
- NeoLabHQ/context-engineering-kit
- Commit
dedca19
- 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.