dotnet-inspect-relationships

Map how code connects — implementors and subclasses, extension methods, dependency graphs, reverse callers, and ecosystem integrations. Many outputs are graph-shaped (add --mermaid).

Quality

58%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Fix and improve this skill with Tessl

tessl review fix ./skills/relationships/SKILL.md

Quality

Content

46%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 a command-rich reference with many executable examples organized by useful questions, but it is monolithic: dense, caveat-laden prose and version-pinned details fill a ~330-line SKILL.md with no progressive disclosure to separate files. Splitting the per-command reference detail into referenced files and tightening the inline overview would substantially improve it.

Suggestions

Move the deep per-section detail (--envelope/Share semantics, graph libraries, integrations filtering) into referenced files (e.g. references/depends.md, references/graphs.md) and keep SKILL.md as a concise overview with one example per command.

Trim opaque edge-case prose ('Shared targets remain distinct incoming edges and appear as revisits in tree output') to the decision-relevant rule, or push it to the relevant reference file.

Isolate time-sensitive version numbers (net10.0/net11.0, pinned package versions) into a clearly labeled compatibility section so the core guidance does not age.

Dimension	Reasoning	Score
Conciseness	The ~330-line body is noticeably verbose: dense caveat-heavy prose ('preserves one occurrence per root-relative parent relationship', multi-paragraph --envelope/Share transport rules) and scattered version-sensitive details (net8.0–net11.0, pinned package versions) that would be better confined to a versioned reference. It avoids explaining basics Claude knows, but much of the edge-case detail could be trimmed or moved out.	2 / 5
Actionability	Concrete, runnable `dnx dotnet-inspect` invocations appear throughout with real packages and TFMs, but several use placeholders the user cannot know ('Type', 'Method:1', 'AddOpenTelemetrySharedProviderBuilderServices~4d95928639'), keeping them just short of copy-paste ready.	4 / 5
Workflow Clarity	Question-headed sections ('What does it depend on?', 'Who calls it?') sequence command selection well, but validation guidance (e.g. 'restore/build first if dependencies changed') is buried in prose rather than presented as explicit checkpoints, and the dense edge-case language leaves gaps in the task-to-command path.	3 / 5
Progressive Disclosure	No bundle files exist and there are no references at all: reference-grade detail (the --envelope/Share contract, graph libraries sections, integrations filtering rules) that clearly belongs in separate files is inlined in one long SKILL.md.	2 / 5
	Total	11 / 20 Passed

Description

71%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 specific, well-scoped description that clearly states what the skill does, but it lacks an explicit 'when to use' trigger clause, which caps its completeness. Adding trigger guidance and a few more natural synonyms would round it out.

Suggestions

Add an explicit trigger clause, e.g. 'Use when the user asks who calls a method, what implements an interface, or how types/packages depend on each other in .NET'.

Include common user phrasings such as 'call hierarchy', 'find usages', or 'references' to broaden trigger coverage.

State the .NET/C# target domain explicitly so it does not compete with relationship-mapping skills for other ecosystems.

Dimension	Reasoning	Score
Specificity	The description lists five concrete capabilities — 'implementors and subclasses, extension methods, dependency graphs, reverse callers, and ecosystem integrations' — giving comprehensive, specific coverage of the skill's actions rather than vague domain language.	5 / 5
Completeness	The 'what' is clear ('Map how code connects — implementors and subclasses...'), but there is no 'Use when...' clause or equivalent trigger guidance; the '(add --mermaid)' parenthetical describes output shape, not when to invoke the skill.	3 / 5
Trigger Term Quality	Natural terms like 'dependency graphs', 'reverse callers', 'extension methods', and 'ecosystem integrations' match what users would say, but common variations such as 'call hierarchy', 'find usages/references', or '.NET/C#' are missing.	4 / 5
Distinctiveness Conflict Risk	The relationship-mapping niche with terms like 'reverse callers' and 'ecosystem integrations' is mostly distinct, with only minor overlap risk against generic code-search or documentation skills.	4 / 5
	Total	16 / 20 Passed

Validation

93%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 15 / 16 Passed

Validation for skill structure

Criteria	Description	Result
frontmatter_unknown_keys	Unknown frontmatter key(s) found; consider removing or moving to metadata	Warning

	Total	15 / 16 Passed

Repository: richlander/dotnet-inspect
Path: skills/relationships/SKILL.md
Commit: 71591ae

Reviewed: 3 days ago

Table of Contents

Discovery Implementation Validation

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.