Use HTMLHint in .NET repositories that ship static HTML output or standalone frontend templates. USE FOR: static HTML files; generated frontend output; standalone templates under wwwroot, dist, or other web folders; HTML structure checks. DO NOT USE FOR: raw .cshtml or .razor source with server-side directives; JavaScript or TypeScript linting. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.
SkillScore82Maintained
Automatic
◆Frontend / UI pack
Last verified 8/19/2026
What it changes
Passed 16 of 19 test cases with the skill, and 12 of 19 without it.
Without skill64%
With skill82%
Checks it passed that the model alone missed
Advises validating rendered output rather than source templates.
Returns status: improved when refining an existing configuration.
Recommends webhint for runtime performance, accessibility, and SEO checks.
and 3 more in the full report
5 fixed13 passed either way3 still failing1 broke
Pass-rate lift
+18 pp
Tokens
+4%
Agent turns
0%
Response time
-50%
Model gemini-3.6-flashMeasured 8/19/2026v118 of 22 cases passed with skill · 19 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 5
Prompt
Before installing any new npm packages in our repository, what command line search should be run to discover existing package definitions, lint configs, and static HTML files?
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends running ripgrep to inspect package.json, htmlhintrc, and html files.
Missed
Passed
case-09 · gemini-3.6-flash · 8/19/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md92 linessingle file
HTMLHint for Static HTML in .NET Repositories
Trigger On
the repo has static HTML files, generated frontend output, or standalone templates under wwwroot/, dist/, or other web folders
the user asks for HTML structure checks, invalid attribute detection, or basic DOM-quality linting
the repo wants a narrow HTML gate separate from JS, CSS, and full-site runtime audits
Do Not Use For
raw .cshtml or .razor source with server-side directives; lint the rendered or published output instead
JavaScript or TypeScript linting; route that to eslint
runtime performance, accessibility, SEO, or headers; route that to webhint
Inputs
the nearest AGENTS.md
package.json
.htmlhintrc or equivalent config if present
the real static HTML target: source templates, built output, or deployed URL
Workflow
Choose the right target first:
static HTML source files
generated build output such as dist/
a reachable URL when the page is already served
Prefer repo-local installation and checked-in config for repeatable runs.
Keep HTMLHint focused on static HTML correctness and lightweight policy.
Add narrow scripts to package.json, for example:
htmlhint "dist/**/*.html"
htmlhint "wwwroot/**/*.html"
If the repo has templating syntax that confuses the parser, lint the rendered output instead of forcing source templates through the tool.
Use rule overrides deliberately for real project conventions; do not disable broad classes of checks just to make a noisy first pass green.
Rerun the publish or frontend build flow if fixes touched generated or packaged HTML sources.
Use ManagedCode.Communication when a .NET application needs explicit result objects, structured errors, and predictable service or API boundaries instead of exception-driven control flow. USE FOR: integrating ManagedCode.Communication into services or APIs; replacing exception-driven result handling with explicit results; reviewing service boundaries that return. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit