metalint
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:metalintlint: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.
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
.metalint/metalint.config.jsplus delegated config files under.metalint/only when the repo wants that consolidated layout. - Verify with:
npx metalintnpx metalint --fix
- Return
status: configuredif the repo now has a working aggregated entrypoint, orstatus: improvedif orchestration was tightened. - Return
status: not_applicablewhen the repo intentionally stays with direct linter commands and does not want the wrapper layer.
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
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
- "Give this repo one frontend lint command."
- "Wrap ESLint, Stylelint, and HTMLHint under Metalint."
- "Use Metalint in GitHub Actions for frontend checks."
More from managedcode/dotnet-skills
dotnet
Primary router skill for broad .NET work. Classify the repo by app model and cross-cutting concern first, then switch to the narrowest matching .NET skill instead of staying at a generic layer.
18dotnet-aspnet-core
Build, debug, modernize, or review ASP.NET Core applications with correct hosting, middleware, security, configuration, logging, and deployment patterns on current .NET.
13dotnet-entity-framework-core
Design, tune, or review EF Core data access with proper modeling, migrations, query translation, performance, and lifetime management for modern .NET applications.
12dotnet-code-review
Review .NET changes for bugs, regressions, architectural drift, missing tests, incorrect async or disposal behavior, and platform-specific pitfalls before you approve or merge them.
11dotnet-architecture
Design or review .NET solution architecture across modular monoliths, clean architecture, vertical slices, microservices, DDD, CQRS, and cloud-native boundaries without over-engineering.
11dotnet-signalr
Implement or review SignalR hubs, streaming, reconnection, transport, and real-time delivery patterns in ASP.NET Core applications.
10