Dotnet-skills dotnet-webhint
Use webhint in .NET repositories that ship browser-facing frontends. Use when a repo needs CLI audits for accessibility, performance, security headers, PWA signals, SEO, or runtime page quality against a served site or built frontend output.
install
source · Clone the upstream repo
git clone https://github.com/managedcode/dotnet-skills
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/managedcode/dotnet-skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/catalog/Tools/webhint/skills/dotnet-webhint" ~/.claude/skills/managedcode-dotnet-skills-dotnet-webhint && rm -rf "$T"
manifest:
catalog/Tools/webhint/skills/dotnet-webhint/SKILL.mdsource content
webhint for Browser-Facing Frontends in .NET Repositories
Trigger On
- the repo ships a browser-facing site and the user asks about accessibility, performance, SEO, security headers, or page quality
- the repo has
,.hintrc
scripts, or a served local frontend that should be auditedhint - the team needs more than syntax linting and wants runtime-oriented site checks
Do Not Use For
- JavaScript or TypeScript semantic linting; route that to
ordotnet-eslintdotnet-biome - stylesheet-only linting; route that to
dotnet-stylelint - static HTML structure checks alone; route that to
dotnet-htmlhint
Inputs
- the nearest
AGENTS.md package.json
if present.hintrc- the real audit target: local dev URL, preview URL, deployed URL, or built output
Workflow
- Choose the audit surface deliberately:
- running local URL such as
https://localhost:3000 - preview or deployed URL
- local connector against built output when no browser runtime is needed
- running local URL such as
- Prefer repo-local installation and a checked-in
..hintrc - Start from a documented preset such as
, then customize only for real repo requirements.web-recommended - Add repeatable scripts to
, for example:package.jsonhint https://localhost:3000hint https://example.test --config .hintrc
- Keep runtime prerequisites explicit:
- supported Node.js version
- browser availability when the connector needs Chromium-based automation
- Treat findings as categorized work:
- headers and transport
- accessibility and HTML issues
- performance
- PWA and manifest signals
- Re-run the audit after fixes on the same URL or build output so results are comparable.
Bootstrap When Missing
- Detect current state:
rg --files -g 'package.json' -g '.hintrc*'rg -n '"hint"' --glob 'package.json' .
- Prefer a repo-local install:
npm install --save-dev hint
- Create or refine
with a known baseline such as.hintrc
.web-recommended - Add repeatable commands to
andAGENTS.md
, then verify with:package.jsonnpx hint https://localhost:3000npx hint -c ./.hintrc https://example.com
- Return
if the repo now has a working site-audit gate, orstatus: configured
if the baseline was tightened.status: improved - Return
when the repo does not expose a stable browser-facing surface that can be audited in the current task.status: not_applicable
Handle Failures
- Missing-browser errors usually mean the environment lacks Chrome, Chromium, or Edge for the selected connector.
- WSL is a poor default for browser-backed runs; prefer a native environment or switch to a
-style connector when appropriate.jsdom
or install-permission failures are usually fixed by installingEACCES
as a repo devDependency instead of relying on a global tool.hint- If the audit target is unstable, authenticated, or still booting, fix the serving workflow first; otherwise the noise is not actionable.
Deliver
- a repeatable webhint audit command and config
- a stable target URL or build-output strategy
- categorized runtime-quality findings the team can act on
Validate
- the audited target matches the site that actually ships
- browser or connector prerequisites are documented
- webhint is not being used as a substitute for ESLint or Stylelint
- reruns on the same target produce consistent comparisons
Ralph Loop
- Plan: analyze current state, target outcome, constraints, and risks.
- Execute one step and produce a concrete delta.
- Review the result and capture findings.
- Apply fixes in small batches and rerun checks.
- Update the plan after each iteration.
- Repeat until outcomes are acceptable.
- If a dependency is missing, bootstrap it or return
with a reason.status: not_applicable
Required Result Format
:status
|complete
|clean
|improved
|configured
|not_applicableblocked
: concise plan and current stepplan
: concrete changes madeactions_taken
: commands, checks, or review evidenceverification
: unresolved items orremainingnone
Example Requests
- "Run webhint against the local frontend before release."
- "Add accessibility and security-header audits for this site."
- "Why does webhint fail in CI but not locally?"