CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

dotnet-devcert-trust

Diagnose and fix .NET HTTPS dev certificate trust issues on Linux. Covers the full certificate lifecycle from generation to system CA bundle inclusion, with distro-specific guidance for Ubuntu, Fedora, Arch, and WSL2.

Quality

79%

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/dotnet-devcert-trust/SKILL.md
SKILL.md
Quality
Evals
Security

Quality

Content

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

Highly actionable and workflow-excellent content — ordered diagnostics, validation checkpoints, and copy-paste commands with expected outputs — but the single-file structure inlines material that belongs in reference files, and the repeated export/install sequence across several sections inflates token cost.

Suggestions

Move the CI/CD (GitHub Actions, Azure DevOps) and distro-specific (Fedora, Arch, WSL2) sections into reference files (e.g. references/ci-cd.md, references/distros.md), keeping a one-line pointer in SKILL.md.

Deduplicate the export→copy→chmod→update-ca-certificates sequence: state it once in the recovery procedure and have other sections reference it instead of repeating it (the two CI YAML blocks are nearly identical and could be a single snippet with a note).

Trim the Quick Reference and pitfall 4 to link back to the full recovery procedure rather than restating the same commands.

DimensionReasoningScore

Conciseness

Command-and-table style with almost no padding of concepts Claude already knows, but the export→copy→chmod→update sequence is repeated verbatim in the recovery script, Fedora notes, pitfall 4, Quick Reference, and two nearly identical GitHub Actions/Azure DevOps YAML blocks — more than minor tightening, matching the mostly-efficient-with-some-unnecessary-repetition anchor.

3 / 5

Actionability

Every step is a copy-paste-ready command with exact paths, permissions, and expected outputs (exit-code tables, "1 added", openssl verify strings), and the full recovery script is complete and executable — matching the fully-executable anchor covering the common cases.

5 / 5

Workflow Clarity

The 5-point diagnostic procedure is explicitly ordered ("Stop at the first FAIL and apply its fix before continuing") with PASS/FAIL tables, re-verification after each fix, and a final openssl verify in the recovery script — explicit validation steps and feedback loops throughout, including for the destructive rm operations.

5 / 5

Progressive Disclosure

Sections are clearly organized with a Quick Reference, but this is a ~415-line monolith with no bundle files at all; CI/CD automation and the per-distro (Fedora, Arch, WSL2) content clearly belong in separate reference files, and the simple-skill exception does not apply at this length.

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

A specific, well-scoped third-person description with strong distinctiveness, but it omits any explicit "when to use" trigger guidance and misses the natural error keywords (UntrustedRoot, dev-certs) that affected users would actually type.

Suggestions

Append an explicit trigger clause, e.g. "Use when `dotnet dev-certs https --check --trust` fails, Redis/gRPC connections report UntrustedRoot, or after `--clean` on a Linux dev machine."

Include the natural failure keywords users say ("UntrustedRoot", "dotnet dev-certs https", "exit code 7") so the skill triggers on real error messages.

Swap the generic "Diagnose and fix" lead-in for the concrete operations the skill performs (generate, export, install to system CA store, rebuild the bundle) to reach full specificity.

DimensionReasoningScore

Specificity

"Diagnose and fix .NET HTTPS dev certificate trust issues on Linux" plus "certificate lifecycle from generation to system CA bundle inclusion" lists several concrete actions across a named domain, matching the several-specific-actions anchor with minor gaps (diagnose/fix are broad verbs rather than fully enumerated operations).

4 / 5

Completeness

The "what" is clear (diagnose, fix, lifecycle coverage, distro guidance) but there is no "Use when..." clause or equivalent explicit trigger guidance, which per the judging guidelines caps completeness at 3; the "when" is only weakly implied by the problem framing.

3 / 5

Trigger Term Quality

Natural terms like ".NET HTTPS dev certificate", "trust", "CA bundle", and the distro names (Ubuntu, Fedora, Arch, WSL2) give good keyword coverage, but common user-side failure phrases such as "UntrustedRoot", "dotnet dev-certs https", or "certificate validation error" are missing, so it falls short of the comprehensive-synonyms anchor.

4 / 5

Distinctiveness Conflict Risk

".NET HTTPS dev certificate trust issues on Linux" carves out a clear niche with distinct triggers (dev cert, CA bundle, specific distros) that virtually no other skill would claim, matching the minimal-conflict anchor.

5 / 5

Total

16

/

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

Aaronontheweb/dotnet-skills

Path

skills/dotnet-devcert-trust/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.