CtrlK
BlogDocsLog inGet started
Tessl Logo

dotnet-inspect-sourcelink

Inspect source mapped by Portable PDB and SourceLink data — map files and member locations, fetch source, or resolve checksum-matched content locally.

61

Quality

72%

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 ./skills/sourcelink/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 highly actionable, with executable command examples and specific flag semantics throughout, organized into clear task-oriented sections. Its main weaknesses are prose density in a few explanatory passages and an implicit rather than explicit step sequence.

Suggestions

Tighten the densest passages, e.g. compress the 'For one package with exactly SourceLink: Files selected...' paragraph into a short bullet list of row-selection flags.

Consider moving detailed flag semantics (--row, --part, URL-form rules) into a references/ file, keeping SKILL.md as a lean overview.

Make the locate → fetch → inspect sequence explicit (e.g. a brief ordered list or decision guidance at the top) so the workflow does not depend on section ordering.

DimensionReasoningScore

Conciseness

Most content is tool-specific and non-derivable ('--repo requires a fully qualified clone path and applies only to raw.githubusercontent.com SourceLink URLs'), but several dense passages — the SourceLink row-selection semantics and the checksum-provenance paragraph — could be noticeably tightened without losing information.

3 / 5

Actionability

Thirteen copy-paste-ready 'dnx dotnet-inspect' commands with concrete package, type, and member names (e.g. 'member JsonSerializer --platform System.Text.Json Serialize:1 -S "PDB Source"') cover the common cases across mapping, fetching, printing, and URL output.

5 / 5

Workflow Clarity

Sections give a clear progression (locate source → fetch PDB source → inspect member parts) with stated failure behavior ('Unavailable parts fail rather than selecting a substitute') and fallbacks to the signals and decompiler skills, but the sequence is carried by section order rather than explicit ordered steps, and validation is implicit in tool behavior.

4 / 5

Progressive Disclosure

The body is a well-sectioned, self-contained document with no nested references (and no bundle files exist to verify), though roughly 40 lines of detailed flag semantics (--row/--part rules, URL forms) could live in a separate reference file.

4 / 5

Total

16

/

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 concrete, domain-specific, and clearly distinguishable from other skills, but it omits any 'when to use' trigger clause and is missing a few natural synonyms. Adding an explicit usage trigger and terms like 'debug symbols' or '.pdb' would round it out.

Suggestions

Add an explicit 'Use when...' clause naming trigger scenarios, e.g. 'Use when inspecting .NET assemblies, Portable PDBs, SourceLink URLs, or checksum-matched source.'

Include natural synonyms and file extensions users would say, such as 'debug symbols', 'PDB files', or '.pdb'.

Consider mentioning the member-part inspection capability (e.g. printing xml-docs, attributes, signature, body) so the description covers what the body documents.

DimensionReasoningScore

Specificity

Names the domain ('Portable PDB and SourceLink') and several concrete actions ('map files and member locations, fetch source, or resolve checksum-matched content locally'), but capabilities documented in the body (member-part printing, rendered URL preference) are absent from the description, leaving minor gaps in coverage.

4 / 5

Completeness

The 'what' is clearly stated (inspect PDB/SourceLink-mapped source, map files and member locations, fetch source, resolve checksum-matched content), but there is no 'Use when...' clause or equivalent explicit trigger guidance, which caps completeness at 3.

3 / 5

Trigger Term Quality

Terms a .NET user would naturally say — 'Portable PDB', 'SourceLink', 'source', 'member locations', 'checksum' — are present, but common synonyms such as 'debug symbols' or the '.pdb' extension are missing.

4 / 5

Distinctiveness Conflict Risk

'Portable PDB and SourceLink data' carves out a very narrow, clearly-owned niche with distinct technical triggers, so conflict with other skills is minimal.

5 / 5

Total

16

/

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