dotnet-metalint
Skill13 starsChanged 8 months agoMITView on GitHub
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.
- 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-htmlhintSkill
- 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-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
12 rules. About 0 are common, 9 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 37
Use Metalint only after those owners are explicit.
- Very specific: line 38
Keep all wrapper configuration under .metalint/ and keep the delegated configs reviewable.
- Distinctive: line 39
Add package scripts such as:
- Distinctive: line 42
Treat formatter overlap carefully.
- Distinctive: line 43
Use Metalint in CI when the repo benefits from a single frontend lint step and formatter output such as GitHub annotations.
- Distinctive: line 51
Prefer a repo-local install:
- Very specific: line 54
Create .metalint/metalint.config.js plus delegated config files under .metalint/ only when the repo wants that consolidated layout.
- Distinctive: line 63
If Metalint says a delegated linter is missing, install that linter or remove it from the wrapper config.
- Distinctive: line 64
If fix mode causes conflicting rewrites, split ownership by glob instead of letting several tools mutate the same files blindly.
- Distinctive: line 65
If the wrapper becomes harder to understand than direct commands, the repo probably does not need Metalint.
- Distinctive: line 87
Update the plan after each iteration.
- Very specific: line 89
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
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."
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.

