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"

64

Quality

75%

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-debugging/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

82%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 tight, highly actionable debugging skill body with concrete tool calls, example I/O, a decision table, and a worked example. The main weakness is mild redundancy across the Workflow, Checklist, and Tools sections, which slightly hurts conciseness and navigation.

Suggestions

Consolidate the overlapping query/context guidance across the Workflow, Checklist, and Tools sections to remove redundancy and tighten the token budget.

Add one explicit verification checkpoint in the workflow (e.g. 'Confirm root cause against source before reporting') to strengthen the feedback loop.

Consider moving the per-tool I/O examples into a single Tools section and trimming their re-listing in the Workflow to improve navigation.

DimensionReasoningScore

Conciseness

Lean body with no concept explanations Claude already knows; uses tables, code blocks, and a checklist efficiently. Not a 5 because query/context appear redundantly across the Workflow, Checklist, and Tools sections, which could be tightened.

4 / 5

Actionability

Fully executable guidance with concrete calls and example inputs plus expected outputs (e.g. query({search_query: ...}) → Processes: ..., Symbols: ...; trace({from, to}) → hops: ...). Copy-paste ready and covers the common debugging cases.

5 / 5

Workflow Clarity

Clear 4-step numbered workflow (query → context → READ process → cypher) plus a checklist and a stale-index feedback hint ('If Index is stale → run node .gitnexus/run.cjs analyze'). Not a 5 because validation checkpoints are light — only 'Read source files to confirm root cause' verifies the conclusion — though this is read-only debugging so the destructive cap does not apply.

4 / 5

Progressive Disclosure

Well-organized into clear sections (When to Use, Workflow, Checklist, Debugging Patterns, Tools, Example) with no nested references and all content appropriately inline for a focused single-purpose skill. No bundle files exist. Not a 5 because the body is ~100 lines (above the under-50 simple-skill threshold) and the Workflow/Checklist/Tools overlap could be consolidated for cleaner navigation.

4 / 5

Total

17

/

20

Passed

Description

68%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 trigger-rich description that excels at 'when' with natural example phrases, but it never states what the skill actually does, leaving the 'what' implicit. Adding a concrete capability clause (e.g. querying code execution flows and tracing call chains via GitNexus) would round it out.

Suggestions

Add an explicit 'what' clause naming the skill's concrete capabilities (e.g. 'Query code execution flows, trace call chains, and inspect caller/callee context via GitNexus') before the 'Use when' trigger.

Mention GitNexus in the description so the skill is distinguishable from generic debugging approaches and conflict risk is reduced.

Consider adding a synonym like 'investigating' alongside 'debugging/tracing' to broaden natural-term coverage.

DimensionReasoningScore

Specificity

Names the debugging domain and a couple of actions ('debugging a bug, tracing an error'), but these describe the user's activity rather than concrete tool capabilities, and no technical actions (e.g. query/context/trace) are stated. Not a 4 because it lacks several specific capability statements; not a 2 because it does name concrete debugging actions.

3 / 5

Completeness

The 'when' is exceptionally explicit ('Use when the user is debugging a bug, tracing an error, or asking why something fails' plus examples), but the 'what' is only implied — the description never states what the skill does (no mention of GitNexus, querying code, or tracing call chains). Not a 4 because there is no explicit 'what' statement; not a 2 because the 'when' is far stronger and more concrete than the score-2 anchor.

3 / 5

Trigger Term Quality

Rich natural trigger phrases users actually say — 'Why is X failing?', 'Where does this error come from?', 'Trace this bug' — plus synonyms (debug/trace/why something fails). Comprehensive coverage of natural terms; not below 5 since no common synonym variant is missing.

5 / 5

Distinctiveness Conflict Risk

The debugging/tracing niche with specific trigger phrases ('Trace this bug', 'Where does this error come from?') is mostly distinct with only minor overlap risk against general coding skills. Not a 5 because 'debugging a bug' is broad and the description omits the GitNexus specificity that would fully carve the niche.

4 / 5

Total

15

/

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.

Validation16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
abhigyanpatwari/GitNexus
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.