1---2name: dotnet-webhint3description: 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.4---56# webhint for Browser-Facing Frontends in .NET Repositories78## Trigger On910- the repo ships a browser-facing site and the user asks about accessibility, performance, SEO, security headers, or page quality11- the repo has `.hintrc`, `hint` scripts, or a served local frontend that should be audited12- the team needs more than syntax linting and wants runtime-oriented site checks1314## Do Not Use For1516- JavaScript or TypeScript semantic linting; route that to `dotnet-eslint` or `dotnet-biome`17- stylesheet-only linting; route that to `dotnet-stylelint`18- static HTML structure checks alone; route that to `dotnet-htmlhint`1920## Inputs2122- the nearest `AGENTS.md`23- `package.json`24- `.hintrc` if present25- the real audit target: local dev URL, preview URL, deployed URL, or built output2627## Workflow28291. Choose the audit surface deliberately:30 - running local URL such as `https://localhost:3000`31 - preview or deployed URL32 - local connector against built output when no browser runtime is needed332. Prefer repo-local installation and a checked-in `.hintrc`.343. Start from a documented preset such as `web-recommended`, then customize only for real repo requirements.354. Add repeatable scripts to `package.json`, for example:36 - `hint https://localhost:3000`37 - `hint https://example.test --config .hintrc`385. Keep runtime prerequisites explicit:39 - supported Node.js version40 - browser availability when the connector needs Chromium-based automation416. Treat findings as categorized work:42 - headers and transport43 - accessibility and HTML issues44 - performance45 - PWA and manifest signals467. Re-run the audit after fixes on the same URL or build output so results are comparable.4748## Bootstrap When Missing49501. Detect current state:51 - `rg --files -g 'package.json' -g '.hintrc*'`52 - `rg -n '"hint"' --glob 'package.json' .`532. Prefer a repo-local install:54 - `npm install --save-dev hint`553. Create or refine `.hintrc` with a known baseline such as `web-recommended`.564. Add repeatable commands to `AGENTS.md` and `package.json`, then verify with:57 - `npx hint https://localhost:3000`58 - `npx hint -c ./.hintrc https://example.com`595. Return `status: configured` if the repo now has a working site-audit gate, or `status: improved` if the baseline was tightened.606. Return `status: not_applicable` when the repo does not expose a stable browser-facing surface that can be audited in the current task.6162## Handle Failures6364- Missing-browser errors usually mean the environment lacks Chrome, Chromium, or Edge for the selected connector.65- WSL is a poor default for browser-backed runs; prefer a native environment or switch to a `jsdom`-style connector when appropriate.66- `EACCES` or install-permission failures are usually fixed by installing `hint` as a repo devDependency instead of relying on a global tool.67- If the audit target is unstable, authenticated, or still booting, fix the serving workflow first; otherwise the noise is not actionable.6869## Deliver7071- a repeatable webhint audit command and config72- a stable target URL or build-output strategy73- categorized runtime-quality findings the team can act on7475## Validate7677- the audited target matches the site that actually ships78- browser or connector prerequisites are documented79- webhint is not being used as a substitute for ESLint or Stylelint80- reruns on the same target produce consistent comparisons8182## Ralph Loop83841. Plan: analyze current state, target outcome, constraints, and risks.852. Execute one step and produce a concrete delta.863. Review the result and capture findings.874. Apply fixes in small batches and rerun checks.885. Update the plan after each iteration.896. Repeat until outcomes are acceptable.907. If a dependency is missing, bootstrap it or return `status: not_applicable` with a reason.9192### Required Result Format9394- `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`95- `plan`: concise plan and current step96- `actions_taken`: concrete changes made97- `verification`: commands, checks, or review evidence98- `remaining`: unresolved items or `none`99100## Example Requests101102- "Run webhint against the local frontend before release."103- "Add accessibility and security-header audits for this site."104- "Why does webhint fail in CI but not locally?"