understand-diff
Use when you need to analyze git diffs or pull requests to understand what changed, affected components, and risks
56
63%
Does it follow best practices?
Impact
—
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./understand-anything-plugin/skills/understand-diff/SKILL.mdQuality
Discovery
50%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 establishes a clear domain (git diff/PR analysis) and includes a 'Use when' clause, which is good. However, it lacks specificity in concrete actions the skill performs and misses common trigger term variations like 'PR review', 'code review', or 'merge request'. The what and when are somewhat blended, making it harder to distinguish from other code-review-related skills.
Suggestions
Add specific concrete actions the skill performs, e.g., 'Summarizes code changes, identifies affected components, flags potential risks and breaking changes in git diffs and pull requests.'
Expand trigger terms to include common variations users would say: 'PR review', 'code review', 'merge request', 'diff', 'code changes', '.patch files'.
Separate the 'what' from the 'when' more clearly, e.g., describe capabilities first, then add 'Use when the user asks to review a PR, analyze a diff, or understand code changes.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (git diffs, pull requests) and some actions (analyze, understand what changed, affected components, risks), but doesn't list multiple concrete specific actions like 'summarize changes, identify breaking changes, flag security risks'. | 2 / 3 |
Completeness | Has a 'Use when' clause which addresses the 'when', but the 'what' is weak — it says 'analyze' and 'understand' but doesn't clearly describe what concrete outputs or actions the skill performs. The 'what' and 'when' are blended together without clearly answering both. | 2 / 3 |
Trigger Term Quality | Includes relevant terms like 'git diffs', 'pull requests', 'what changed', and 'risks', but misses common variations users might say such as 'PR review', 'code review', 'diff analysis', 'merge request', or 'code changes'. | 2 / 3 |
Distinctiveness Conflict Risk | Focuses on git diffs and pull requests which is a reasonably specific niche, but 'analyze' and 'understand what changed' could overlap with general code review skills or git-related skills. The mention of 'affected components' and 'risks' adds some distinction but not enough to be fully clear. | 2 / 3 |
Total | 8 / 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 well-crafted skill with a clear, actionable multi-step workflow for analyzing git diffs against a knowledge graph. Its main strength is the highly specific, executable instructions with concrete commands and output schemas. The main weakness is the inlined graph structure reference which adds bulk that could be separated, and a few tips in 'How to Read Efficiently' that are somewhat obvious for Claude.
Suggestions
Consider moving the Graph Structure Reference section to a separate file (e.g., GRAPH_SCHEMA.md) and referencing it, to reduce the main skill's token footprint.
Remove or condense the 'How to Read Efficiently' section — tips like 'don't dump the entire graph into context' and 'node names and summaries are the most useful fields' are largely self-evident to Claude.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The graph structure reference section is useful but somewhat verbose — Claude could infer some of this from the JSON itself. The 'How to Read Efficiently' tips are reasonable but partially obvious (e.g., 'don't dump the entire graph into context'). Overall mostly efficient with some tightening possible. | 2 / 3 |
Actionability | The instructions are highly concrete and sequential: specific git commands for different scenarios, exact grep strategies for finding nodes and edges, a complete JSON schema for the output file, and clear fallback behavior (telling user to run /understand first). Every step is directly executable. | 3 / 3 |
Workflow Clarity | The 8-step workflow is clearly sequenced with explicit ordering, each step builds on the previous one's output (changed files → matched nodes → connected edges → layers → analysis → output file). Step 1 is a validation checkpoint. The parenthetical notes clarify when to use which git command variant. The structured analysis output format provides a clear deliverable. | 3 / 3 |
Progressive Disclosure | The content is well-organized with clear sections (Graph Structure Reference, How to Read Efficiently, Instructions), but the graph structure reference is inlined rather than being in a separate reference file. For a skill of this length (~80 lines of substantive content), some of the reference material could be split out. However, no bundle files exist to support this, and the single-file approach is workable. | 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.
- Repository
- Lum1104/Understand-Anything
- Commit
26edf61
- 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.