Use Metalint in .NET repositories that ship Node-based frontend assets and want one CLI entrypoint over several underlying linters. USE FOR: unified frontend lint commands; combined ESLint, Stylelint, HTMLHint, or similar checks; CI orchestration over multiple frontend linters. DO NOT USE FOR: simple repos where Biome already covers the required surface; teams that have not decided which underlying linters own each file type. INVOKES: inspect the repository context, edit targeted files, and run
SkillScore86Maintained
Automatic
◆Coding pack
Last verified 8/19/2026
What it changes
Passed 16 of 19 test cases with the skill, and 8 of 19 without it.
Without skill41%
With skill86%
Checks it passed that the model alone missed
The response specifies invoking metalint in CI steps.
The response includes configured as an allowed status value.
The response includes not_applicable as an allowed status value.
and 10 more in the full report
10 fixed9 passed either way3 still failing0 broke
Pass-rate lift
+45 pp
Tokens
+6%
Agent turns
0%
Response time
-58%
Model gemini-3.6-flashMeasured 8/19/2026v219 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 10 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 10
Prompt
When setting up consolidated frontend linting configurations, in which exact directory path should all wrapper configuration files be placed?
What was checked, without and with the skill
Checked
Without skill
With skill
The response specifies placing wrapper configuration under the .metalint directory.
Missed
Passed
case-15 · 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.md100 linessingle file
Metalint for Aggregated Frontend Linting in .NET Repositories
Trigger On
the repo wants one command to run several frontend linters together
the user asks for a unified lint entrypoint over ESLint, Stylelint, HTMLHint, or similar tools
the repo already has multiple linters and the problem is orchestration rather than choosing a single owner
Do Not Use For
simple repos where one tool such as Biome already covers the required surface
teams that have not decided which underlying linters own JS, CSS, and HTML yet
replacing the underlying linter configs with one vague wrapper config
Inputs
the nearest AGENTS.md
package.json
existing linter configs
any .metalint/ directory already checked in
Workflow
Define underlying ownership first:
ESLint for JS or TS
Stylelint for CSS or SCSS
HTMLHint for static HTML
other delegated linters only when the repo really uses them
Use Metalint only after those owners are explicit.
Keep all wrapper configuration under .metalint/ and keep the delegated configs reviewable.
Add package scripts such as:
lint: metalint
lint:fix: metalint --fix
Treat formatter overlap carefully. If delegated tools can all fix files, define which ones are allowed to mutate which globs.
Use Metalint in CI when the repo benefits from a single frontend lint step and formatter output such as GitHub annotations.
Re-run the underlying owners directly when debugging Metalint issues so failures stay attributable.
Current Upstream Notes
Metalint v0.22.0 adds Bun and Deno project support, links source and types for JSR slow-type compatibility, and supports npm-check-updates 21.
Use the Microsoft.Extensions stack correctly across Generic Host, dependency injection, configuration, logging, options, HttpClientFactory, and other shared infrastructure patterns. USE FOR: wiring dependency injection, configuration, logging, or options; introducing Generic Host patterns into non-web .NET apps; cleaning up service registration, typed HTTP. DO NOT USE FOR: unrelated stacks; generic tasks that do not need this specific guidance. INVOKES: inspect the repository context, edit targe