CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

gitnexus-exploring

Use when the user asks how code works, wants to understand architecture, trace execution flows, or explore unfamiliar parts of the codebase. Examples: "How does X work?", "What calls this function?", "Show me the auth flow"

Quality

75%

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

Fix and improve this skill with Tessl

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

Quality

Content

88%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.

The body is lean, highly actionable operational guidance: exact tool-call syntax, explicit staleness validation with a re-analyze feedback loop, a checklist, and a worked example. It never pads with concepts Claude already knows; the only real costs are mild repetition of the repo-binding/freshness rules and a single-file layout that is slightly longer than a pure overview.

DimensionReasoningScore

Conciseness

The body is dense, tool-specific operational guidance with almost no explanation of concepts Claude already knows. Minor redundancy — the repo-binding rule and "report repository and index freshness" each appear about three times (prose, checklist, example) — keeps it at anchor 4 (efficient, minor instances that could be trimmed) rather than 5.

4 / 5

Actionability

Calls are copy-paste ready with exact parameter syntax (e.g. `query({search_query: "payment processing", limit: 3, max_symbols: 3})`, `context({uid: "<id>"})`), plus a concrete command (`node .gitnexus/run.cjs analyze`) and a worked end-to-end example covering the common case. This matches anchor 5.

5 / 5

Workflow Clarity

A clear numbered sequence is backed by explicit validation (hot-tool staleness check with decision rules for `behind`/`diverged`), a feedback loop (stale index → re-analyze), stop conditions, ambiguity handling ("stop and ask"), and a checklist. This matches anchor 5; the read-only nature of the skill means the destructive/batch validation cap does not apply.

5 / 5

Progressive Disclosure

A single-file skill with no bundle files, well-organized into clear sections (When to Use, Bind, Workflow, evidence discipline, Checklist, Resources, Tools, Example) and a resource table with token costs. At ~139 lines some detailed option-negotiation and tool-example content could arguably live in a reference file, which fits anchor 4 (good structure, minor organization gaps) rather than 5.

4 / 5

Total

18

/

20

Passed

Description

48%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.

The description excels at natural trigger phrases and explicit use-when guidance, but it never states what the skill actually does — its capabilities are only implied through user intents. Actions listed mix one concrete capability ("trace execution flows") with generic intents ("explore unfamiliar parts of the codebase").

Suggestions

Add a 'what' clause stating the skill's mechanism and concrete capabilities, e.g. "Query a GitNexus code index for symbols, callers/callees, and execution flows" before the 'Use when' clause.

Replace generic intents like "understand architecture" and "explore unfamiliar parts of the codebase" with specific actions such as "find callers of a function", "map functional areas", or "follow a process step-by-step".

Add one or two more natural trigger variations users would say, such as "Where is this defined?" or "Who calls this?", to round out keyword coverage.

DimensionReasoningScore

Specificity

The description names the domain and a couple of actions ("trace execution flows", "understand architecture"), but the latter and "explore unfamiliar parts of the codebase" are generic intents, and the skill's actual capabilities are never stated. This matches anchor 3 (domain plus 1-2 concrete actions, not comprehensive) rather than 4, which requires several specific actions.

3 / 5

Completeness

Only a "when" is present ("Use when the user asks how code works...") with no "what" clause stating what the skill does; capabilities must be inferred, which the guidelines forbid. This exactly matches anchor 2 (only 'when' present without 'what') and not anchor 3, which requires a clear 'what'.

2 / 5

Trigger Term Quality

Quoted phrases like "How does X work?", "What calls this function?", and "Show me the auth flow" are natural user utterances with good coverage. Not anchor 5 because common variants such as "where is this defined?" or "who calls this?" are absent.

4 / 5

Distinctiveness Conflict Risk

Triggers like "how code works" and "understand architecture" are broad and would overlap with general code-reading or search skills, though execution-flow tracing is somewhat distinct. Fits anchor 3 (somewhat specific but overlap risk with similar skills), not 4.

3 / 5

Total

12

/

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

abhigyanpatwari/GitNexus

Path

.claude/skills/gitnexus-exploring/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.