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, hint scripts, or a served local frontend that should be audited
• the team needs more than syntax linting and wants runtime-oriented site checks

Workflow

1. 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

1. Prefer repo-local installation and a checked-in .hintrc.
2. Start from a documented preset such as web-recommended, then customize only for real repo requirements.
3. Add repeatable scripts to package.json, for example:

- hint https://localhost:3000 - hint https://example.test --config .hintrc

1. Keep runtime prerequisites explicit:

- supported Node.js version - browser availability when the connector needs Chromium-based automation

1. Treat findings as categorized work:

- headers and transport - accessibility and HTML issues - performance - PWA and manifest signals

1. Re-run the audit after fixes on the same URL or build output so results are comparable.

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

Related skills

Related agents