CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

dotnet-inspect-query

Discover dotnet-inspect capabilities and query rules, select inspection sections, and shape answers with common formats, projections and limits; follow installed explanation for deeper contracts.

Quality

74%

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

Quality

Content

75%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 dense, executable reference for a niche CLI: nearly every token carries non-obvious contract knowledge, commands are copy-paste ready, and the flow from intent to discovery to output shaping is coherent with explicit status-preservation checks. Its main limitations are a handful of directives without accompanying commands and a few passages compressed to the edge of clarity.

DimensionReasoningScore

Conciseness

Nearly every sentence conveys tool-specific contract knowledge Claude cannot know (flag semantics, HAL nesting, packet behavior) with no padding or explanations of known concepts; a few convoluted passages (legacy --rows composition, "Preserve scope (profile, population and completeness)...") could be tightened, keeping it just short of lean perfection.

4 / 5

Actionability

Provides abundant copy-paste-ready commands ("dnx dotnet-inspect -y -- find JsonSerializer -n 5 --table", jq pipelines, workspace packet flows), but a few directives like "use -Q before constructing --where or --order-by" and "Discover the route's selection contract" lack a showing command, leaving minor gaps.

4 / 5

Workflow Clarity

A clear progression runs from intent shaping through a result-lookup table, discovery with -D/-S/-Q, output arguments, and boundaries, with explicit checkpoints ("Check the command's exit status", "zero rows with incomplete evaluation is not absence", "Stop once the requested answer has sufficient evidence"), though checkpoints are informal rather than structured validate-fix-retry loops.

4 / 5

Progressive Disclosure

The single-file body is well-sectioned with headers, tables, and fenced commands, and appropriately delegates deep contracts to the tool's own installed explanation system instead of inlining them; some dense sections (HAL/vocabulary jq detail, workspace packet semantics) could be split into reference files, which is a minor organization gap.

4 / 5

Total

16

/

20

Passed

Description

62%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 states concrete, tool-specific actions and is highly distinct, but it omits any explicit "when to use" trigger guidance and lacks the natural vocabulary (.NET, API, package, library) users would employ. Adding a Use-when clause and those trigger terms would lift the two weakest dimensions.

Suggestions

Add an explicit trigger clause, e.g. "Use when the user wants to inspect .NET APIs, packages, or libraries with dotnet-inspect, or asks to find types, members, or packages."

Include natural trigger terms users would actually say: ".NET", "API", "package", "library", "DLL", "find types/members", so the skill surfaces for questions phrased without the tool name.

Replace the abstract "common formats, projections and limits" with named concrete formats (e.g. "table, TSV, JSON output; column/field projections; row windows and limits") to strengthen specificity.

DimensionReasoningScore

Specificity

Lists several concrete actions — "Discover dotnet-inspect capabilities and query rules", "select inspection sections", "shape answers with common formats, projections and limits", "follow installed explanation" — but "common formats, projections and limits" stays abstract, so coverage has minor gaps rather than being comprehensive.

4 / 5

Completeness

The "what" is clear (discover capabilities, select sections, shape output), but there is no "Use when..." clause or equivalent trigger guidance, which caps completeness at 3 per the rubric guidelines.

3 / 5

Trigger Term Quality

"dotnet-inspect" is a strong tool-name trigger alongside "inspection" and "query", but natural user phrases like ".NET", "API", "package", "library/DLL", or "find types/members" are missing, so common variations and synonyms are absent.

3 / 5

Distinctiveness Conflict Risk

It names a specific niche CLI tool ("dotnet-inspect") with tool-specific vocabulary, giving it a clear niche with distinct triggers and minimal conflict risk with any other skill.

5 / 5

Total

15

/

20

Passed

Validation

93%

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

CriteriaDescriptionResult

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/query/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.