CtrlK
BlogDocsLog inGet started
Tessl Logo

speckit-git-commit

Auto-commit changes after a Spec Kit command completes

60

Quality

71%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/speckit-git-commit/SKILL.md

The canonical home for this skill is speckit-git-commit in unoplatform/uno

SKILL.md
Quality
Evals
Security

Quality

Content

80%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 body is a tight, highly actionable instruction sheet: exact script invocations for Bash and PowerShell, a complete commented config example, and explicit graceful-degradation behavior. Its one substantive weakness is the absence of any validation or verification around the batch `git add .` + commit operation, which the rubric caps at 3 for workflow clarity; a lighter issue is the duplicated event-name explanation.

Suggestions

Add a verification step after committing, e.g. check the commit succeeded (`git log -1 --stat`) and report the resulting commit hash — this lifts the batch-operation validation cap on workflow clarity.

Show what happens when the commit fails (e.g., pre-commit hooks rejecting the commit) and what to do, closing the feedback loop for the batch `git add .` operation.

Deduplicate event-name determination: keep it in one place (Execution) and trim the second example list of event names from the Behavior step.

DimensionReasoningScore

Conciseness

The body is lean and free of explanations of concepts Claude already knows, but event-name determination is explained twice — "Determines the event name from the hook context (e.g., if invoked as an `after_specify` hook...)" in Behavior step 1 and again in the Execution intro — plus a second example list of event names. These minor duplications match anchor 4 ("Efficient; minor instances of over-explanation that could be trimmed") rather than 5's "every token earns its place".

4 / 5

Actionability

The skill gives exact copy-paste-ready commands for both shells (".specify/extensions/git/scripts/bash/auto-commit.sh <event_name>", ".../powershell/auto-commit.ps1 <event_name>"), explains placeholder substitution with concrete examples (after_specify, before_plan, after_implement), and includes a complete, commented config YAML block. This matches anchor 5 ("Fully executable; copy-paste ready code or commands; specific examples cover the common cases").

5 / 5

Workflow Clarity

The sequence is clearly laid out (numbered Behavior steps, Execution, Configuration, Graceful Degradation), but the core operation — "runs `git add .` + `git commit`" over all changes — is a batch operation with no validation or verification step (no check of what is being staged, no confirmation the commit succeeded). The rubric's judging guideline caps batch operations without validation at workflow clarity 3, and this cap takes precedence over the simple-skill exception, so 3 rather than 4.

3 / 5

Progressive Disclosure

The skill is under 50 lines, needs no external reference files (none exist in the bundle), and is organized into well-signaled sections (Behavior, Execution, Configuration, Graceful Degradation). Per the rubric's guidance, a sub-50-line skill with no need for external references scores 5 with just well-organized sections.

5 / 5

Total

17

/

20

Passed

Description

62%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 is concise, third-person, and states both what the skill does and when it applies, anchored clearly to the Spec Kit domain. Its main weaknesses are thin trigger-term coverage (missing natural synonyms like "git" and the underlying command names) and a single-action framing that undersells the skill's staging, messaging, and config-driven behavior.

Suggestions

Add a 'Use when...' style trigger clause with natural phrases users would say, e.g. "Use when working in a Spec Kit project and the user wants changes committed after commands like specify, plan, or implement run".

Include common trigger synonyms and specifics: 'git', 'auto-commit', 'commit changes', and the underlying command names (specify, plan, implement) to improve keyword coverage and distinctiveness.

Broaden the capability statement from one action to a few concrete ones, e.g. "Stages and commits all changes with per-command configurable messages, gated by .specify/extensions/git/git-config.yml".

DimensionReasoningScore

Specificity

"Auto-commit changes after a Spec Kit command completes" names the domain and one concrete action (committing changes), but stops short of listing several specific actions such as staging, per-command messages, or config-driven toggling. It fits anchor 3 ("Names domain and 1-2 concrete actions, but not comprehensive") rather than 4, which requires several specific actions.

3 / 5

Completeness

The "what" is clear (auto-commit changes) and the "when" is explicitly stated ("after a Spec Kit command completes"), but it could be more specific about which commands or the config gating. This fits anchor 4 ("Has both 'what' and 'when'; 'when' could be more explicit or specific") — not 3, since the when-clause is explicit rather than merely implied.

4 / 5

Trigger Term Quality

Relevant keywords like "auto-commit", "commit", and "Spec Kit" are present, but common variations a user would naturally say — "git", "save changes", "specify", "plan", "implement" — are missing. This matches anchor 3 ("Some relevant keywords but missing common variations or synonyms"), not 4 ("Good keyword coverage").

3 / 5

Distinctiveness Conflict Risk

"Spec Kit" carves out a clear niche, but the bare phrase "commit changes" could overlap with generic git-commit or commit-message skills when a user mentions committing. This matches anchor 4 ("Mostly distinct; minor overlap risk with closely related skills") rather than 5, which demands minimal conflict risk.

4 / 5

Total

14

/

20

Passed

Validation

93%

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

CriteriaDescriptionResult

metadata_version

'metadata.version' is missing

Warning

Total

15

/

16

Passed

Repository
mixpanel/mixpanel-headless
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.