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---5
6# webhint for Browser-Facing Frontends in .NET Repositories
7
8## Trigger On
9
10- the repo ships a browser-facing site and the user asks about accessibility, performance, SEO, security headers, or page quality
11- the repo has `.hintrc`, `hint` scripts, or a served local frontend that should be audited
12- the team needs more than syntax linting and wants runtime-oriented site checks
13
14## Do Not Use For
15
16- 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`
19
20## Inputs
21
22- the nearest `AGENTS.md`
23- `package.json`
24- `.hintrc` if present
25- the real audit target: local dev URL, preview URL, deployed URL, or built output
26
27## Workflow
28
291. Choose the audit surface deliberately:
30 - running local URL such as `https://localhost:3000`
31 - preview or deployed URL
32 - local connector against built output when no browser runtime is needed
332. 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 version
40 - browser availability when the connector needs Chromium-based automation
416. Treat findings as categorized work:
42 - headers and transport
43 - accessibility and HTML issues
44 - performance
45 - PWA and manifest signals
467. Re-run the audit after fixes on the same URL or build output so results are comparable.
47
48## Bootstrap When Missing
49
501. 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.
61
62## Handle Failures
63
64- 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.
68
69## Deliver
70
71- a repeatable webhint audit command and config
72- a stable target URL or build-output strategy
73- categorized runtime-quality findings the team can act on
74
75## Validate
76
77- the audited target matches the site that actually ships
78- browser or connector prerequisites are documented
79- webhint is not being used as a substitute for ESLint or Stylelint
80- reruns on the same target produce consistent comparisons
81
82## Ralph Loop
83
841. 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.
91
92### Required Result Format
93
94- `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`
95- `plan`: concise plan and current step
96- `actions_taken`: concrete changes made
97- `verification`: commands, checks, or review evidence
98- `remaining`: unresolved items or `none`
99
100## Example Requests
101
102- "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?"