dotnet-htmlhint
Skill13 starsChanged 8 months agoMITView on GitHub
Use HTMLHint in .NET repositories that ship static HTML output or standalone frontend templates. Use when a repo needs a focused CLI lint gate for DOM structure, invalid attributes, and basic HTML correctness checks on static pages.
- Installs packages
In this repository84 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- dotnet-analyzer-configSkill
- dotnet-architectureSkill
- dotnet-archunitnetSkill
- dotnet-aspireSkill
- dotnet-aspnet-coreSkill
- dotnet-asynkron-profilerSkill
- dotnet-azure-functionsSkill
- dotnet-biomeSkill
- dotnet-blazorSkill
- dotnet-chousSkill
- dotnet-clocSkill
- dotnet-code-analysisSkill
- dotnet-codeqlSkill
- dotnet-code-reviewSkill
- dotnet-complexitySkill
- dotnet-coverletSkill
- dotnet-csharpierSkill
- dotnet-entity-framework6Skill
- dotnet-entity-framework-coreSkill
- dotnet-eslintSkill
- dotnet-formatSkill
- dotnet-grpcSkill
- dotnet-legacy-aspnetSkill
- dotnet-libvlcSkill
- dotnet-managedcode-communicationSkill
- dotnet-managedcode-markitdownSkill
- dotnet-managedcode-mimetypesSkill
- dotnet-managedcode-orleans-graphSkill
- dotnet-managedcode-orleans-signalrSkill
- dotnet-managedcode-storageSkill
- dotnet-mauiSkill
- dotnet-mcaf-agile-deliverySkill
- dotnet-mcaf-devexSkill
- dotnet-mcaf-documentationSkill
- dotnet-mcaf-feature-specSkill
- dotnet-mcaf-human-review-planningSkill
- dotnet-mcaf-ml-ai-deliverySkill
- dotnet-mcaf-nfrSkill
- dotnet-mcafSkill
- dotnet-mcaf-source-controlSkill
- dotnet-mcaf-ui-uxSkill
- dotnet-mcpSkill
- dotnet-metalintSkill
- dotnet-meziantou-analyzerSkill
- dotnet-microsoft-agent-frameworkSkill
- dotnet-microsoft-extensions-aiSkill
- dotnet-microsoft-extensionsSkill
- dotnet-minimal-apisSkill
- dotnet-mixed-realitySkill
- dotnet-mlnetSkill
- dotnet-modern-csharpSkill
- dotnet-mstestSkill
- dotnet-mvvmSkill
- dotnet-netarchtestSkill
- dotnet-nunitSkill
- dotnet-orleansSkill
- dotnet-profilingSkill
- dotnet-project-setupSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 6 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 36
Prefer repo-local installation and checked-in config for repeatable runs.
- Distinctive: line 37
Keep HTMLHint focused on static HTML correctness and lightweight policy.
- Very specific: line 38
Add narrow scripts to package.json, for example:
- Distinctive: line 41
If the repo has templating syntax that confuses the parser, lint the rendered output instead of forcing source templates through the tool.
- Distinctive: line 42
Use rule overrides deliberately for real project conventions.
- Distinctive: line 50
Prefer a repo-local install:
- Very specific: line 52
Add or refine .htmlhintrc only after confirming the actual target files.
- Very specific: line 53
Add repeatable commands to AGENTS.md and package.json, then verify with:
- Distinctive: line 84
Update the plan after each iteration.
- Very specific: line 86
If a dependency is missing, bootstrap it or return status: not_applicable with a reason.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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
.cshtmlor.razorsource with server-side directives; lint the rendered or published output instead - JavaScript or TypeScript linting; route that to
dotnet-eslint - runtime performance, accessibility, SEO, or headers; route that to
dotnet-webhint
Inputs
- the nearest
AGENTS.md package.json.htmlhintrcor 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.
Bootstrap When Missing
- Detect current state:
rg --files -g 'package.json' -g '.htmlhintrc*' -g '*.html'rg -n '"htmlhint"' --glob 'package.json' .
- Prefer a repo-local install:
npm install --save-dev htmlhint
- Add or refine
.htmlhintrconly after confirming the actual target files. - Add repeatable commands to
AGENTS.mdandpackage.json, then verify with:npx htmlhint "dist/**/*.html"npx htmlhint https://example.com
- Return
status: configuredif HTMLHint now owns a clear static-HTML gate, orstatus: improvedif the existing setup was tightened. - Return
status: not_applicablewhen the repo's HTML is primarily server-rendered templates that should be validated after rendering instead.
Handle Failures
- Parser noise on Razor, Blazor, or other server-side template syntax is a target-selection problem; lint built output instead of source templates.
- URL-based checks can fail on auth, SPA routing, or environment drift; verify the served target is reachable and stable before trusting the result.
- Large volumes of trivial attribute warnings usually mean the config was copied from another stack and needs to be adapted to the repo's real HTML conventions.
Deliver
- a repeatable static HTML lint gate
- clear targeting rules for source HTML versus rendered output
- checked-in config that matches the repo's actual page structure
Validate
- the lint target contains real static HTML, not unsupported template syntax
- commands are reproducible from repo-local dependencies
- HTMLHint ownership is kept separate from broader site-audit tooling
- fixes were verified on the built or served output that actually ships
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
- "Add HTMLHint for the built static site in this repo."
- "Lint the generated HTML before deployment."
- "Why is HTMLHint failing on Razor pages?"
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

