CtrlK
BlogDocsLog inGet started
Tessl Logo

gitnexus-debugging

Use when the user is debugging a bug, tracing an error, or asking why something fails. Examples: "Why is X failing?", "Where does this error come from?", "Trace this bug"

60

Quality

68%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Low

Low-risk findings worth noting

Fix and improve this skill with Tessl

tessl review fix ./.claude/skills/gitnexus/gitnexus-debugging/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

72%

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

The content is highly actionable with concrete, executable tool calls and a clear end-to-end worked example, and it is well organized as a single lean file. The main gaps are redundant restatements of the same flow and the absence of explicit validation checkpoints in the workflow.

Suggestions

Consolidate the query -> context -> trace flow so it appears fully once (e.g., in the Workflow) and is only referenced elsewhere, reducing redundancy across the Checklist, Patterns, Tools, and Example sections.

Add an explicit validation checkpoint in the workflow, e.g. 'Confirm root cause in source before concluding' as a gated step rather than only a checklist item.

Make the stale-index recovery aside a clearly signaled conditional step in the main sequence so the feedback loop is part of the workflow rather than a footnote.

DimensionReasoningScore

Conciseness

The body is lean and never explains concepts Claude already knows, but the same query -> context -> trace flow is restated across the Workflow, Checklist, Patterns table, Tools, and Example sections, which could be tightened. Not 3 because of this redundancy; above 1 because there is no padding or known-concept explanation.

2 / 3

Actionability

Concrete, copy-paste-ready tool calls with exact argument shapes (query({query: ...}), context({name: ...})), a real cypher query, a real READ URI, and a concrete recovery command, each with realistic outputs. Not 2 because nothing is pseudocode or abstract.

3 / 3

Workflow Clarity

A clear numbered 4-step sequence plus a checklist and a worked example ending in a root cause, but no explicit validation checkpoints or validate-then-proceed feedback loops in the main flow. Not 3 because validation steps are implicit rather than explicit; not 1 because the sequence is complete and well-ordered.

2 / 3

Progressive Disclosure

A single well-organized SKILL.md under 50 lines of substance with no bundle files and clear sections (When to Use, Workflow, Checklist, Patterns, Tools, Example), matching the simple-skill allowance for a 3. Not 2 because it is not a monolithic wall of text.

3 / 3

Total

10

/

12

Passed

Description

65%

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 has excellent natural trigger terms and clear 'when to use' guidance, but it never states what the skill actually does, leaving the 'what' only implied. Adding a concrete capability statement (e.g., tracing call graphs and execution flows via GitNexus) would raise completeness and specificity.

Suggestions

Add a concrete statement of what the skill does before the 'Use when' clause, e.g. 'Traces bugs through code by querying call graphs and execution flows with GitNexus.'

Mention the core capabilities (query, context, cypher tracing) so the description answers 'what does this do' as clearly as it answers 'when to use it'.

Tighten distinctiveness by referencing GitNexus specifically in the description rather than only generic debugging language.

DimensionReasoningScore

Specificity

Names the debugging/tracing domain and gives example triggers, but describes the user's actions rather than the skill's concrete capabilities (no mention of querying call graphs or tracing execution flow). Not 3 because it lists no specific actions the skill itself performs; above 1 because it is not fully vague.

2 / 3

Completeness

The 'when' is explicit and strong ('Use when...'), but the 'what' is only implied — the description never states what the skill does, which caps completeness at 2. Not 3 because what-it-does is missing; not 1 because the trigger guidance is explicit.

2 / 3

Trigger Term Quality

Natural phrases like 'debugging a bug', 'tracing an error', 'Why is X failing?', and 'Trace this bug' are exactly what a user would say, with good coverage of variations.

3 / 3

Distinctiveness Conflict Risk

'Debugging a bug / tracing an error' is a broad trigger that could overlap with general debugging skills, though the example phrasings give it a somewhat distinct niche. Not 3 because debugging is not a clearly bounded niche; not 1 because it is not generic.

2 / 3

Total

9

/

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
mindfold-ai/Trellis
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.