Dotnet-skills dotnet-metalint
Use Metalint in .NET repositories that ship Node-based frontend assets and want one CLI entrypoint over several underlying linters. Use when a repo wants to orchestrate ESLint, Stylelint, HTMLHint, and related frontend checks from a single checked-in `.metalint/` configuration.
install
source · Clone the upstream repo
git clone https://github.com/managedcode/dotnet-skills
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/managedcode/dotnet-skills "$T" && mkdir -p ~/.claude/skills && cp -r "$T/catalog/Tools/Metalint/skills/dotnet-metalint" ~/.claude/skills/managedcode-dotnet-skills-dotnet-metalint && rm -rf "$T"
manifest:
catalog/Tools/Metalint/skills/dotnet-metalint/SKILL.mdsource content
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
directory already checked in.metalint/
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
and keep the delegated configs reviewable..metalint/ - Add package scripts such as:
:lintmetalint
:lint:fixmetalint --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.
Bootstrap When Missing
- Detect current state:
rg --files -g 'package.json' -g '.metalint/**' -g 'eslint.config.*' -g 'stylelint.config.*' -g '.htmlhintrc*'rg -n '"metalint"|"eslint"|"stylelint"|"htmlhint"' --glob 'package.json' .
- Prefer a repo-local install:
npm install --save-dev metalint
- Install the delegated linters the repo actually needs; Metalint does not replace them.
- Create
plus delegated config files under.metalint/metalint.config.js
only when the repo wants that consolidated layout..metalint/ - Verify with:
npx metalintnpx metalint --fix
- Return
if the repo now has a working aggregated entrypoint, orstatus: configured
if orchestration was tightened.status: improved - Return
when the repo intentionally stays with direct linter commands and does not want the wrapper layer.status: not_applicable
Handle Failures
- If Metalint says a delegated linter is missing, install that linter or remove it from the wrapper config; Metalint cannot invent the underlying tool.
- If fix mode causes conflicting rewrites, split ownership by glob instead of letting several tools mutate the same files blindly.
- If the wrapper becomes harder to understand than direct commands, the repo probably does not need Metalint.
- Debug noisy failures by running the delegated linter directly first, then come back to Metalint integration.
Deliver
- one repeatable frontend lint entrypoint
- explicit delegated-tool ownership
- wrapper config that stays readable and attributable
Validate
- each delegated linter is actually installed and configured
- fix ownership is explicit across file types
- CI output remains attributable to the right underlying tool
- Metalint reduced operational friction instead of hiding the real owners
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
with a reason.status: not_applicable
Required Result Format
:status
|complete
|clean
|improved
|configured
|not_applicableblocked
: concise plan and current stepplan
: concrete changes madeactions_taken
: commands, checks, or review evidenceverification
: unresolved items orremainingnone
Example Requests
- "Give this repo one frontend lint command."
- "Wrap ESLint, Stylelint, and HTMLHint under Metalint."
- "Use Metalint in GitHub Actions for frontend checks."