git-workflow
Always invoke this skill for any git-related request (commit messages, staging review, history, PR descriptions, etc.) so git workflows are handled consistently.
Install with Tessl CLI
npx tessl i github:ceshine/ceshine-agent-skills --skill git-workflow77
Does it follow best practices?
If you maintain this skill, you can automatically optimize it using the tessl CLI to improve its score:
npx tessl skill review --optimize ./path/to/skillValidation for skill structure
Discovery
64%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 effectively communicates when to use the skill (any git-related request) and includes good trigger terms, but fails to explain what the skill actually does beyond 'handling workflows consistently.' It reads more like a routing instruction than a capability description, leaving Claude without clear understanding of the skill's specific functions.
Suggestions
Replace the vague 'handled consistently' with specific actions like 'Generates commit messages, reviews staged changes, analyzes git history, drafts PR descriptions'
Restructure to lead with concrete capabilities before the 'Use when...' trigger clause to clearly answer 'what does this do'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (git) and lists several actions (commit messages, staging review, history, PR descriptions), but these are parenthetical examples rather than concrete capability descriptions. Lacks detail on what the skill actually does with these. | 2 / 3 |
Completeness | Has a clear 'when' clause ('for any git-related request') but the 'what' is weak - it only says workflows are 'handled consistently' without explaining what actions the skill performs. The purpose is stated but capabilities are vague. | 2 / 3 |
Trigger Term Quality | Includes natural keywords users would say: 'git', 'commit messages', 'staging', 'history', 'PR descriptions'. These are terms users naturally use when requesting git-related help. | 3 / 3 |
Distinctiveness Conflict Risk | Git-specific focus provides some distinctiveness, but 'any git-related request' is broad and could overlap with other skills that touch version control, code review, or development workflows. | 2 / 3 |
Total | 9 / 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 solid, actionable skill with clear workflows and good validation checkpoints. The main weakness is moderate verbosity - some explanations of concepts Claude knows (conventional commit format) and some redundancy between sections. The skill would benefit from slight tightening and potentially splitting detailed reference content into separate files.
Suggestions
Remove or condense the conventional commit format explanation - Claude already knows this format well
Consider extracting the detailed PR description template and error handling into separate reference files to improve progressive disclosure
Tighten section 3 by removing the explicit reference back to section 1 and instead just saying 'Review staged changes as described above'
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The skill is mostly efficient but includes some redundancy, such as repeating the staged changes review process reference in section 3 and explaining conventional commit format that Claude already knows. Some sections could be tightened. | 2 / 3 |
Actionability | Provides concrete, executable commands for both MCP tools and bash fallbacks. Clear code examples with specific syntax, and step-by-step procedures that are directly actionable. | 3 / 3 |
Workflow Clarity | Multi-step processes are clearly sequenced with explicit checkpoints (e.g., 'Only move on after explicit approval from user'). The commit message workflow includes validation steps and user feedback loops before proceeding. | 3 / 3 |
Progressive Disclosure | Content is well-organized with clear sections, but everything is inline in a single file. For a skill of this length (~100 lines), some content like the detailed PR description format or error handling could be split into referenced files. | 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.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- 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.