CtrlK
BlogDocsLog inGet started
Tessl Logo

git-best-practices

Git workflow patterns for commits, branching, PRs, and history management across heterogeneous repositories. Use when creating commits, managing branches, opening pull requests, or rewriting history. Do not use for non-git implementation tasks or repo-specific release policy decisions without repository documentation.

90

1.50x
Quality

88%

Does it follow best practices?

Impact

90%

1.50x

Average score across 3 eval scenarios

SecuritybySnyk

Passed

No known issues

SKILL.md
Quality
Evals
Security

Quality

Discovery

100%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This is a strong skill description that clearly defines its scope around git workflow operations, provides explicit 'Use when' and 'Do not use' guidance, and includes natural trigger terms users would employ. The inclusion of negative boundaries ('Do not use for...') is a notable strength that helps distinguish it from adjacent skills.

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions: commits, branching, PRs, and history management. Also specifies 'heterogeneous repositories' and mentions rewriting history, which adds further specificity.

3 / 3

Completeness

Clearly answers both 'what' (git workflow patterns for commits, branching, PRs, history management) and 'when' (explicit 'Use when' clause with triggers, plus a 'Do not use' clause that further clarifies boundaries).

3 / 3

Trigger Term Quality

Includes strong natural trigger terms users would say: 'commits', 'branching', 'pull requests', 'PRs', 'history', 'git'. These cover common variations of how users discuss git workflows.

3 / 3

Distinctiveness Conflict Risk

Clearly scoped to git workflow operations with distinct triggers. The 'Do not use' clause explicitly excludes non-git implementation tasks and repo-specific release decisions, reducing conflict risk with coding or release management skills.

3 / 3

Total

12

/

12

Passed

Implementation

77%

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

This is a strong, actionable git workflow skill with clear sequencing, validation checkpoints, and excellent concrete examples. Its main weakness is moderate verbosity — some content (full commit type table, extensive examples) could be trimmed or split into reference files. The workflow clarity is excellent, with explicit safety gates for destructive operations like force pushes and history rewrites.

Suggestions

Move the conventional commit type table and extended commit examples into a separate reference file (e.g., COMMIT_EXAMPLES.md) to reduce the main skill's token footprint.

Trim the commit type table — Claude already knows what 'docs', 'test', 'ci', and 'style' mean; a shorter list of the less obvious types with brief notes would suffice.

DimensionReasoningScore

Conciseness

Generally efficient and avoids explaining basic git concepts, but some sections are slightly verbose — e.g., the merge strategy rationale column, the full conventional commit type table (Claude knows these), and the branch flow ASCII diagram could be tightened. The commit examples are valuable but collectively take significant space.

2 / 3

Actionability

Highly actionable throughout: executable bash commands for branch discovery (with fallbacks), concrete commit message examples covering multiple scenarios, explicit staging commands, force-push syntax, and PR creation guidance. Nearly every instruction is copy-paste ready.

3 / 3

Workflow Clarity

The agent git workflow is clearly sequenced (check state → discover branches → stage → commit → push) with explicit validation checkpoints (verify with git status, confirm with user before force push, verify byte-for-byte match before rewriting history). The history rewriting workflow includes a backup-then-verify feedback loop. Destructive operations (force push, history rewrite) have explicit user confirmation gates.

3 / 3

Progressive Disclosure

The content is well-organized with clear headers and logical sections, but it's a single monolithic file with no references to supporting documents. The commit examples section and branch discovery fallbacks could be split into separate reference files. For a skill of this length (~200 lines), some progressive disclosure into bundle files would improve scannability.

2 / 3

Total

10

/

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.

Validation11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository
NeverSight/skills_feed
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.