Agent skill
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 this agent skill to your Project
npx add-skill https://github.com/managedcode/dotnet-skills/tree/main/catalog/Tools/webhint/skills/dotnet-webhint
SKILL.md
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,hintscripts, or a served local frontend that should be audited - 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
dotnet-eslintordotnet-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.hintrcif present- 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
web-recommended, then customize only for real repo requirements. - Add repeatable scripts to
package.json, for example:hint 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
.hintrcwith a known baseline such asweb-recommended. - Add repeatable commands to
AGENTS.mdandpackage.json, then verify with:npx hint https://localhost:3000npx hint -c ./.hintrc https://example.com
- Return
status: configuredif the repo now has a working site-audit gate, orstatus: improvedif the baseline was tightened. - Return
status: not_applicablewhen the repo does not expose a stable browser-facing surface that can be audited in the current task.
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
jsdom-style connector when appropriate. EACCESor install-permission failures are usually fixed by installinghintas a repo devDependency instead of relying on a global tool.- 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
status: not_applicablewith a reason.
Required Result Format
status:complete|clean|improved|configured|not_applicable|blockedplan: concise plan and current stepactions_taken: concrete changes madeverification: commands, checks, or review evidenceremaining: unresolved items ornone
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?"
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
dotnet-project-setup
Create or reorganize .NET solutions with clean project boundaries, repeatable SDK settings, and a maintainable baseline for libraries, apps, tests, CI, and local development.
csharp-scripts
Run single-file C# programs as scripts (file-based apps) for quick experimentation, prototyping, and concept testing. Use when the user wants to write and execute a small C# program without creating a full project.
dotnet-pinvoke
Correctly call native (C/C++) libraries from .NET using P/Invoke and LibraryImport. Covers function signatures, string marshalling, memory lifetime, SafeHandle, and cross-platform patterns. USE FOR: writing new P/Invoke or LibraryImport declarations, reviewing or debugging existing native interop code, wrapping a C or C++ library for use in .NET, diagnosing crashes, memory leaks, or corruption at the managed/native boundary. DO NOT USE FOR: COM interop, C++/CLI mixed-mode assemblies, or pure managed code with no native dependencies.
nuget-trusted-publishing
Set up NuGet trusted publishing (OIDC) on a GitHub Actions repo — replaces long-lived API keys with short-lived tokens. USE FOR: trusted publishing, NuGet OIDC, keyless NuGet publish, migrate from NuGet API key, NuGet/login, secure NuGet publishing. DO NOT USE FOR: publishing to private feeds or Azure Artifacts (OIDC is nuget.org only). INVOKES: shell (powershell or bash), edit, create, ask_user for guided repo setup.
dotnet-legacy-aspnet
Maintain classic ASP.NET applications on .NET Framework, including Web Forms, older MVC, and legacy hosting patterns, while planning realistic modernization boundaries.
dotnet-code-review
Review .NET changes for bugs, regressions, architectural drift, missing tests, incorrect async or disposal behavior, and platform-specific pitfalls before you approve or merge them.
Didn't find tool you were looking for?