CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

understand-diff

Use when you need to analyze git diffs or pull requests to understand what changed, affected components, and risks

Quality

87%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

86%Weight 40%Scale 1-5

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

A lean, highly actionable instruction body that documents only skill-specific knowledge and provides a clearly sequenced workflow with explicit graph-freshness validation and error-recovery paths. The residual weaknesses are small: the PR-diff step lacks a concrete command, and there is no guidance for changed files that match no nodes in the graph.

Suggestions

Give a concrete command for the PR case in step 2 (e.g., 'gh pr diff <number> --name-only') instead of 'get the diff from that PR'.

Add a fallback in steps 4–5 for changed files with no matching graph nodes (e.g., newly created files), such as noting them as un-analyzed additions in the report.

Show one concrete grep pattern for tracing a node ID through the edges section (e.g., a jq or grep example) to make the 1-hop affected-component lookup copy-paste ready.

DimensionReasoningScore

Conciseness

The body teaches only what Claude cannot already know: the knowledge-graph JSON schema, the legacy-vs-new data directory resolution, and the '-- .' pathspec monorepo subtlety. There is no generic git/grep explanation or padding, and even the densest passage (step 3 freshness rules) encodes non-obvious edge-case guidance, matching anchor 5 rather than 4.

5 / 5

Actionability

Concrete commands appear throughout: the UA_DIR resolution one-liner, git diff commands, the rev-parse verification block, grep patterns, and a full JSON spec for diff-overlay.json. Minor gaps remain — the PR-number case says 'get the diff from that PR' with no command, and steps 4–5 give no concrete grep pattern for finding edges by node ID — so it fits anchor 4 rather than 5's fully copy-paste-ready coverage.

4 / 5

Workflow Clarity

Eight well-sequenced steps with explicit validation in step 1 (file-exists check with a recovery path: 'run /understand first') and step 3 (freshness check with warn/refresh/best-effort-continue recovery). It is not 5 because steps 4–6 have no fallback when grep finds no matching nodes (e.g., newly added files absent from the graph), leaving a minor validation gap mid-workflow; it is well above 3 since checkpoints are explicit rather than implicit.

4 / 5

Progressive Disclosure

No bundle files exist and none are needed: the skill is a single well-organized document with clear section headers, and the compact graph-structure reference is load-bearing for the grep steps so inlining it is appropriate. The one external pointer ('/understand-anything:understand-dashboard') is clearly signaled. This matches anchor 5 — content appropriately placed with easy navigation.

5 / 5

Total

18

/

20

Passed

Description

83%Weight 40%Scale 1-5

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

A strong description that explicitly covers what the skill does and when to use it with natural trigger terms, in third person, with no padding. It stops just short of top marks because the action verbs are minimal and a few natural synonyms (e.g., 'impact', 'code review') are absent.

DimensionReasoningScore

Specificity

The description names the domain ('analyze git diffs or pull requests') and several concrete deliverables ('what changed, affected components, and risks'), but the verb set is thin ('analyze', 'understand') rather than enumerating multiple distinct concrete actions. This matches anchor 4 (several specific actions with minor gaps in coverage) rather than 5.

4 / 5

Completeness

It explicitly answers both 'what' ('understand what changed, affected components, and risks') and 'when' with concrete trigger phrases ('Use when you need to analyze git diffs or pull requests'). It matches anchor 5; it is not 4 because the when-clause is explicit and trigger-specific rather than merely present but improvable.

5 / 5

Trigger Term Quality

'git diffs', 'pull requests', 'what changed', 'affected components', and 'risks' are natural phrases users would say, giving good keyword coverage. Common synonyms like 'review changes', 'impact analysis', or 'blast radius' are missing, so it fits anchor 4 rather than 5's comprehensive synonym coverage.

4 / 5

Distinctiveness Conflict Risk

It has a clear niche (diff impact analysis focused on affected components and risks) that distinguishes it from generic diff viewing. There is minor overlap risk with code-review or commit-message skills that also trigger on 'git diffs' or 'pull requests', matching anchor 4 rather than 5's minimal conflict risk.

4 / 5

Total

17

/

20

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 — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

Egonex-AI/Understand-Anything

Path

understand-anything-plugin/skills/understand-diff/SKILL.md

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.