dotnet-webhint

Runs webhint audits for accessibility, performance, security headers, and SEO against .NET frontend sites.

Updated Mar 31, 2026
One-click install
npx skills add https://github.com/zhenpengLai/myuseskill --skill dotnet-webhint-zhenpenglai
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dotnet-webhint
Source: https://github.com/zhenpengLai/myuseskill/tree/main/dotnet-webhint
Command: npx skills add https://github.com/zhenpengLai/myuseskill --skill dotnet-webhint-zhenpenglai

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires hint.

What problem does it solve? .NET repositories that ship browser-facing frontends often lack repeatable runtime quality checks, leaving accessibility issues, missing security headers, and SEO problems undetected until after release. ## Core Features & Use Cases - Runtime Site Audits: Runs webhint against local dev URLs, preview URLs, deployed sites, or built frontend output to check accessibility, performance, security headers, PWA signals, and SEO. - Repeatable Configuration: Sets up a repo-local hint devDependency, a checked-in .hintrc based on presets like web-recommended, and repeatable package.json scripts. - Failure Diagnosis: Handles common issues such as missing Chromium-based browsers, WSL limitations, and EACCES install errors. - Use Case: Before a release, ask the agent to audit https://localhost:3000 and receive categorized findings covering headers, accessibility, performance, and PWA signals that the team can act on. ## Quick Start Run a webhint audit against my local frontend at https://localhost:3000 and set up a repeatable audit script in package.json.

Frequently Asked Questions about dotnet-webhint

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run webhint against a local development site?▼

Install hint as a repo devDependency with npm install --save-dev hint, then run npx hint https://localhost:3000. Add the command to package.json scripts so the audit is repeatable across the team.

What is the difference between webhint and ESLint or Stylelint?▼

webhint audits runtime page quality such as accessibility, security headers, performance, and SEO against a served site. ESLint handles JavaScript and TypeScript semantic linting, while Stylelint handles stylesheet linting; webhint is not a substitute for either.

Does webhint require a browser to run audits?▼

Some webhint connectors need a Chromium-based browser such as Chrome or Edge for automation. When no browser runtime is needed, you can use a local connector against built output or a jsdom-style connector instead.

Why does webhint fail in CI but work locally?▼

CI failures usually come from missing Chrome, Chromium, or Edge for the selected connector, or from an unstable audit target that is still booting or requires authentication. Document browser prerequisites and stabilize the serving workflow first.

Can I run webhint in WSL?▼

WSL is a poor default for browser-backed webhint runs. Prefer a native environment, or switch to a jsdom-style connector when browser automation is not required.

When should I not use webhint for frontend checks?▼

Do not use webhint for JavaScript or TypeScript semantic linting, stylesheet-only linting, or static HTML structure checks alone. Route those to ESLint, Stylelint, or HTMLHint respectively, and reserve webhint for runtime-oriented site audits.