CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

speckit-git-commit

Disabled — commits are performed manually by the user, never by Spec Kit

60

Quality

76%

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 g14wx/staffSync

SKILL.md
Quality
Evals
Security

Quality

Content

92%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 an exemplary instruction-only guard skill: a crisp no-op policy with concrete forbidden operations, an exact fallback message, precise config/file references, and a clearly gated re-enable procedure. Its only blemish is mild repetition of the 'never commit' prohibition and a rationale section that could be tightened by a line or two.

Suggestions

State the core prohibition once in Behavior and close with the existing bolded 'never commit' — drop the duplicate phrasing in the intro paragraph.

Condense the three-bullet Rationale to a single line (e.g. 'Commit format requires Trello-aware data and user-owned granularity; see task.md') to tighten conciseness toward anchor 5.

DimensionReasoningScore

Conciseness

The body is lean and assumes Claude's competence — no git basics, no concept explanations — but the core prohibition is stated three times (intro, Behavior item 1, closing 'Until then: **never commit.**') and the three-bullet Rationale could be condensed to one line. This matches anchor 4 (efficient, minor over-explanation that could be trimmed), not anchor 3's 'some unnecessary explanation' and not anchor 5's every-token-earns-its-place.

4 / 5

Actionability

For an instruction-only no-op skill the guidance is fully executable: exact forbidden operations ("git add, git commit, or any mutating git operation"), an exact copy-paste output string ('[spec-kit] auto-commit disabled by project policy; commit manually'), exact config keys ("auto_commit.<event>.enabled") and file paths ('.specify/extensions/git/git-config.yml'), plus a concrete misconfiguration response. Anchor 5's 'specific examples cover the common cases' is met.

5 / 5

Workflow Clarity

This is a simple single-purpose skill whose single action (return immediately, optionally emit one informational line) is unambiguous, and it even includes an edge-case checkpoint (hook wiring still calling auto-commit.sh → treat as misconfiguration, report, do not commit). The destructive/batch cap does not apply since the skill exists to prevent mutations, so the simple-skill exception yields 5.

5 / 5

Progressive Disclosure

The body is under 50 lines, has no need for external reference files (none exist in the bundle), and is organized into clean, well-labeled sections (Behavior, Rationale, Execution, Re-enabling). Per the rubric's simple-skill note, this earns 5 with well-organized sections alone.

5 / 5

Total

19

/

20

Passed

Description

50%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 communicates the disabled status and the manual-commit policy clearly and concisely, but it is written as a status label rather than a skill description: it lacks any 'when to use' trigger guidance and the natural trigger terms (git commit, auto-commit) that would let a user or Claude find it. It does not over-claim and contains no fluff.

Suggestions

Add an explicit trigger clause, e.g. 'Use when Spec Kit or a hook asks to auto-commit changes' — this would raise completeness above the cap of 3.

Include natural terms users would actually say, such as 'git commit', 'auto-commit', or 'commit changes', to improve trigger-term coverage.

State the skill's actual behavior in the description (e.g. 'Enforces project policy that Spec Kit never stages or commits; returns a no-op when invoked') so the 'what' is a capability statement, not just a status.

DimensionReasoningScore

Specificity

"Disabled — commits are performed manually by the user, never by Spec Kit" names the domain (git commits, Spec Kit) and one concrete policy, but does not list multiple specific actions. It fits anchor 3 (domain plus 1-2 concrete statements) — clearer than the generic anchor 2, but not the 'several specific actions' of anchor 4.

3 / 5

Completeness

The 'what' is explicit (the skill is disabled; commits happen manually, never via Spec Kit), but there is no 'Use when...' clause or equivalent trigger guidance, which caps completeness at 3 per the judging guidelines. Not anchor 4, which requires both what and when.

3 / 5

Trigger Term Quality

Relevant keywords are present ("commits", "Spec Kit") but common variations a user would naturally say — "git commit", "auto-commit", "commit message" — are missing. This matches anchor 3 (some relevant keywords, missing variations/synonyms) rather than anchor 4's good coverage.

3 / 5

Distinctiveness Conflict Risk

"Spec Kit" gives it a niche, but the only action keyword ("commits") overlaps with general commit-message and commit-automation skills, and no distinct trigger phrase separates it. It sits between anchors 3 and 4 — somewhat specific but with real overlap risk.

3 / 5

Total

12

/

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

g14wx/staffSync

Path

.claude/skills/speckit-git-commit/SKILL.md

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.