git
Git workflow conventions for Graph Explorer. Use when making commits, creating branches, or discussing version control practices.
88
81%
Does it follow best practices?
Impact
100%
1.08xAverage score across 3 eval scenarios
Passed
No known issues
Quality
Discovery
89%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 solid description with a clear 'Use when...' clause and good trigger terms. Its main weakness is that it could be more specific about what conventions it actually covers (e.g., commit message format, branch naming patterns, merge strategies). The project-scoping to 'Graph Explorer' helps with distinctiveness.
Suggestions
Add specific concrete actions like 'Defines commit message format, branch naming conventions, and merge/rebase strategies for Graph Explorer' to improve specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (git workflow conventions for Graph Explorer) and some actions (making commits, creating branches), but doesn't list specific concrete actions like commit message format, branch naming conventions, or merge strategies. | 2 / 3 |
Completeness | Clearly answers both what ('Git workflow conventions for Graph Explorer') and when ('Use when making commits, creating branches, or discussing version control practices') with an explicit 'Use when...' clause. | 3 / 3 |
Trigger Term Quality | Includes natural keywords users would say: 'commits', 'branches', 'version control', 'git'. These are terms a user would naturally use when needing this skill. 'Graph Explorer' also serves as a good project-specific trigger. | 3 / 3 |
Distinctiveness Conflict Risk | The combination of 'Git workflow conventions' scoped specifically to 'Graph Explorer' creates a clear niche. The triggers (commits, branches, version control) are distinct and unlikely to conflict with non-git skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
72%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a very concise conventions skill that clearly communicates the project's git workflow rules. Its main weakness is the lack of concrete examples — a good/bad commit message example or a sample workflow would significantly boost actionability without adding much length.
Suggestions
Add 2-3 concrete examples of good commit messages following these conventions (and optionally a bad example showing what to avoid with prefixes).
Consider adding a brief example workflow showing the expected sequence: e.g., make change → stage → commit with example message → push to main.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Extremely lean — four bullet points with zero fluff. Every token earns its place and nothing explains concepts Claude already knows. | 3 / 3 |
Actionability | The rules are clear and specific (no prefixes, single trunk branch), but there are no concrete examples of good vs bad commit messages or branch names to make the guidance fully actionable. | 2 / 3 |
Workflow Clarity | The conventions are stated clearly, but there's no sequenced workflow for how to actually perform a commit or branch operation following these rules. For a simple conventions skill this is acceptable but an example workflow (e.g., 'make change → commit with brief message → push to main') would improve clarity. | 2 / 3 |
Progressive Disclosure | For a simple, sub-50-line skill with no need for external references, the content is well-organized as a concise bullet list. No bundle files are needed. | 3 / 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.
- Repository
- aws/graph-explorer
- Commit
30587b0
- 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.