CtrlK
BlogDocsLog inGet started
Tessl Logo

git-workflow-monorepo

Provides Git monorepo workflow standards covering branching strategy, semantic version release tagging, commit message formats, pull request guidelines, and merge conflict resolution. Use when the user asks about branching, versioning, commit conventions, PR reviews, or resolving merge conflicts in a monorepo.

59

Quality

67%

Does it follow best practices?

Impact

No eval scenarios have been run

SecuritybySnyk

Passed

No known issues

Optimize this skill with Tessl

npx tessl skill review --optimize ./skills/git-workflow-monorepo/SKILL.md
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 articulates specific capabilities, includes natural trigger terms, and explicitly states both what the skill does and when to use it. The monorepo focus provides good distinctiveness, and the enumeration of specific workflow areas (branching, versioning, commits, PRs, merge conflicts) gives Claude clear signals for skill selection.

DimensionReasoningScore

Specificity

Lists multiple specific concrete actions: branching strategy, semantic version release tagging, commit message formats, pull request guidelines, and merge conflict resolution. These are all distinct, well-defined capabilities.

3 / 3

Completeness

Clearly answers both 'what' (provides Git monorepo workflow standards covering branching, tagging, commits, PRs, merge conflicts) and 'when' (explicit 'Use when...' clause listing specific trigger scenarios).

3 / 3

Trigger Term Quality

Includes natural keywords users would say: 'branching', 'versioning', 'commit conventions', 'PR reviews', 'merge conflicts', 'monorepo'. These cover common variations of how users would phrase requests in this domain.

3 / 3

Distinctiveness Conflict Risk

The 'monorepo' qualifier combined with the specific Git workflow topics (branching strategy, semantic versioning, commit formats, PR guidelines) creates a clear niche that is unlikely to conflict with general Git skills or other development workflow skills.

3 / 3

Total

12

/

12

Passed

Implementation

35%

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

This skill reads more like a team onboarding wiki page than a targeted Claude skill. It is overly verbose, explaining many concepts Claude already knows (semantic versioning definitions, what merge conflict markers look like, generic advice like 'communicate with your team'). The actionable content—branch naming conventions, commit message format, and the develop-next edge case—is buried in explanatory prose that doesn't earn its token cost.

Suggestions

Remove explanations of concepts Claude already knows: semantic versioning definitions, how merge conflict markers work, what `git status` and `git add` do, and generic team advice like 'communicate with your team'.

Add concrete, copy-paste-ready Git command sequences for key workflows (e.g., creating a feature branch, tagging a release candidate, performing a hotfix merge back to develop).

Restructure as a concise reference with a quick-reference table for branch naming conventions and commit format at the top, moving detailed edge cases and PR guidelines to separate referenced files.

Add explicit validation checkpoints to the release tagging and hotfix workflows (e.g., 'verify CI passes before merging to main', 'confirm tag exists with `git tag -l`').

DimensionReasoningScore

Conciseness

The content is very verbose, explaining many concepts Claude already knows well (what semantic versioning is, what merge conflict markers look like, general advice like 'communicate with your team'). Sections like 'Understanding and Resolving Merge Conflicts' explain basic Git concepts (git status, conflict markers, git add) that add no value. The PR best practices section reads like a generic onboarding document rather than a targeted skill.

1 / 3

Actionability

The skill provides some concrete guidance like branch naming conventions (develop-PROJ-<ticket-number>) and commit message format (PROJ-123: description), but most content is descriptive policy rather than executable instructions. There are no code blocks with actual Git commands to run, no templates, and the examples are minimal. It describes what should happen rather than giving copy-paste-ready commands.

2 / 3

Workflow Clarity

The branching strategy implies a multi-step workflow (feature branch → develop → main) and the release tagging process has a sequence, but neither is presented as a clear numbered workflow with validation checkpoints. The hotfix flow mentions merging main back into develop but doesn't provide explicit steps or verification. The edge case for develop-next is reasonably sequenced but lacks validation steps.

2 / 3

Progressive Disclosure

The content is organized into logical sections with headers, which helps navigation. However, it's a monolithic document with no references to supporting files, and several sections (merge conflict resolution, PR best practices) could be split out. For a skill of this length (~150 lines of substantive content), inline presentation of everything reduces scannability.

2 / 3

Total

7

/

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
ucdavis/ai-skills-registry
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.