Install
$ agentstack add skill-postpartum-genushyacinthus29-dotnet-skills-dotnet-metalint ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
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."
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: Postpartum-genushyacinthus29
- Source: Postpartum-genushyacinthus29/dotnet-skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.