git-commit
Use when creating git commits to ensure commit messages follow project standards. Applies the 7 rules for great commit messages with focus on conciseness and imperative mood.
84
80%
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 ./.agents/skills/git-commit/SKILL.mdQuality
Discovery
75%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 is well-structured with an explicit 'Use when' clause and a clear niche around git commit message formatting. Its main weakness is moderate specificity—it references '7 rules' without enumerating key ones—and trigger term coverage could be broader to capture more natural user phrasings.
Suggestions
Add more specific concrete actions, e.g., 'Formats subject lines under 50 chars, separates subject from body, wraps body at 72 characters'.
Expand trigger terms to include variations like 'commit msg', 'staged changes', 'git log', or 'conventional commits' to improve matching.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (git commits) and some actions (creating commit messages, applying 7 rules, imperative mood, conciseness), but doesn't list multiple concrete specific actions like 'analyze diffs', 'format subject lines', 'wrap body at 72 chars'. | 2 / 3 |
Completeness | Clearly answers both what ('Applies the 7 rules for great commit messages with focus on conciseness and imperative mood') and when ('Use when creating git commits to ensure commit messages follow project standards') with an explicit 'Use when' trigger clause. | 3 / 3 |
Trigger Term Quality | Includes 'git commits' and 'commit messages' which are natural terms users would say, but misses common variations like 'commit msg', 'staged changes', 'git message', 'conventional commits', or file references like '.gitcommit'. | 2 / 3 |
Distinctiveness Conflict Risk | Clearly scoped to git commit message formatting with specific methodology (7 rules, imperative mood), making it unlikely to conflict with other skills like general git operations or code review skills. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
85%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured, actionable skill that provides clear guidance for writing commit messages. Its strengths are the concrete examples (both good and bad), the executable HEREDOC format, and the pre-commit checklist. The main weakness is mild verbosity in the Key Principles and Bad Examples sections, where some explanations could be trimmed without losing clarity.
Suggestions
Trim the 'Key Principles' section — lines like 'Every word should add value' and 'Be concise, not verbose' are meta-advice Claude already understands; keep only project-specific constraints like 'no bullet points' and 'no references to review feedback'.
Condense the bad examples: the problem annotations are helpful but the second bad example's body text is intentionally long, which itself consumes tokens — a shorter bad example with a one-line annotation would suffice.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some unnecessary content. The 'Bad Examples' section with detailed explanations of why they're bad adds bulk, and the 'Key Principles' section partially restates things Claude already knows (e.g., 'Every word should add value'). The good/bad example contrast is useful but could be tighter. | 2 / 3 |
Actionability | Provides concrete, copy-paste ready format with the HEREDOC bash command, specific good and bad examples with clear contrast, and an actionable checklist. The 7 rules are specific and unambiguous, and the examples demonstrate exactly what to produce. | 3 / 3 |
Workflow Clarity | For a single-task skill (writing commit messages), the workflow is clear and unambiguous: follow the 7 rules, use the HEREDOC format, check against the checklist before committing. The checklist serves as an explicit validation checkpoint, which is appropriate for this non-destructive operation. | 3 / 3 |
Progressive Disclosure | For a self-contained skill under 80 lines with no need for external references, the content is well-organized into logical sections (rules, principles, format, examples, checklist) that are easy to scan and navigate. No bundle files are needed. | 3 / 3 |
Total | 11 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- cloudflare/sandbox-sdk
- Commit
f03920a
- 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.