CtrlK
BlogDocsLog inGet started
Tessl Logo

gitnexus-impact-analysis

Use when the user wants to know what will break if they change something, or needs safety analysis before editing code. Examples: "Is it safe to change X?", "What depends on this?", "What will break?"

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

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./gitnexus-cursor-integration/skills/gitnexus-impact-analysis/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

81%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 highly actionable and workflow-rich, with concrete tool calls, CLI fallbacks, explicit validation checkpoints, and a realistic worked example. Its only real weakness is that some explanatory prose in the binding and risk sections could be tightened for token efficiency.

Suggestions

Tighten the "Bind the repository first" paragraph — the pagination, default-policy, and ambiguity guidance could be condensed into a shorter decision rule.

Consider moving the detailed risk-field semantics (riskSharedAxes, riskScale.unusedAxes, group vs single-repo mode) into a short reference table to reduce inline prose.

DimensionReasoningScore

Conciseness

Mostly efficient and information-dense with gitnexus-specific gotchas (false clean checks, wrong-worktree zeros, partial/truncated flags), but the "Bind the repository first" and "Risk Assessment" prose could be tightened in places.

3 / 5

Actionability

Provides fully executable tool calls with complete arguments, CLI fallbacks (`node .gitnexus/run.cjs impact "X" --direction upstream --repo .`), and a worked end-to-end example with realistic output covering the common case.

5 / 5

Workflow Clarity

A clearly sequenced 0–4 workflow plus a checklist, with explicit validation checkpoints (re-run on stale index, re-run on partial/truncated, stop on UNKNOWN, confirm the diffed checkout) and feedback loops for this destructive edit-gate operation.

5 / 5

Progressive Disclosure

Well-organized into distinct sections with a one-level resource reference (`gitnexus://repo/{name}/processes`) and no nested file chains; no bundle files exist, so structure is internal only, leaving minor room to externalize the detailed gotchas.

4 / 5

Total

17

/

20

Passed

Description

70%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 is strong, with explicit "Use when" framing and concrete example trigger phrases that users would naturally say. The main weakness is that the capability is implied through triggers rather than stated as a comprehensive list of specific actions.

Suggestions

Lead with a concise standalone capability statement (e.g., "Performs upstream blast-radius and dependency analysis on code changes") before the "Use when" clause.

Add 1–2 more concrete actions (e.g., "find dependents", "check affected execution flows") to broaden specificity beyond the two currently implied.

DimensionReasoningScore

Specificity

Names the domain (impact/break analysis) and 1–2 concrete actions — "know what will break" and "safety analysis before editing code" — but does not enumerate a comprehensive list of specific actions, matching the 3-anchor.

3 / 5

Completeness

Has both a "what" (what-will-break / safety analysis) and an explicit "when" with concrete trigger examples, though the capability statement is embedded in the when-clause rather than a crisp standalone assertion.

4 / 5

Trigger Term Quality

Quotes natural user phrases ("Is it safe to change X?", "What depends on this?", "What will break?") plus "safety analysis", giving good keyword coverage with a few synonyms missing.

4 / 5

Distinctiveness Conflict Risk

Targets a clear niche (pre-edit impact/safety analysis) with distinct triggers, carrying only minor overlap risk with generic code-editing guidance.

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.