Use ESLint in .NET repositories that ship JavaScript, TypeScript, React, or other Node-based frontend assets. USE FOR: the repo has package.json, eslint.config.*, .eslintrc*, tsconfig.json, or JS/TS/React frontend files; the user asks for JavaScript or TypeScript linting, React rule. DO NOT USE FOR: CSS ownership by itself; route that to stylelint; HTML-only checks on static output; route that to htmlhint. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test
SkillScore68Maintained
Automatic
◆Frontend / UI pack
Last verified 8/19/2026
What it changes
Passed 12 of 18 test cases with the skill, and 10 of 18 without it.
Without skill55%
With skill68%
Checks it passed that the model alone missed
The response defines 'lint' as 'eslint .'.
The response defines 'lint:fix' as 'eslint . --fix'.
The response specifies HTMLHint instead of ESLint for HTML checks.
and 4 more in the full report
6 fixed9 passed either way4 still failing3 broke
Pass-rate lift
+14 pp
Tokens
+47%
Agent turns
0%
Response time
-29%
Model gemini-3.6-flashMeasured 8/19/2026v315 of 22 cases passed with skill · 18 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 6 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 6
Prompt
We have static HTML build outputs and standalone markup templates in our ASP.NET project that need automated validation for missing close tags and invalid HTML attributes. Set up the dedicated tool for checking raw HTML output quality and structure your response with status, plan, actions_taken, verification, and remaining.
What was checked, without and with the skill
Checked
Without skill
With skill
The response specifies HTMLHint instead of ESLint for HTML checks.
Missed
Passed
The output contains status, plan, actions_taken, verification, and remaining keys.
Passed
Passed
case-05 · 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.md103 linessingle file
ESLint for Frontend Assets in .NET Repositories
Trigger On
the repo has package.json, eslint.config.*, .eslintrc*, tsconfig.json, or JS/TS/React frontend files
the user asks for JavaScript or TypeScript linting, React rule enforcement, import hygiene, or unsafe frontend patterns
CI should fail on frontend lint findings instead of relying on editor-only feedback
Do Not Use For
CSS ownership by itself; route that to stylelint
HTML-only checks on static output; route that to htmlhint
repos that intentionally standardized on Biome as the only JS or TS formatter-linter, unless migration or comparison is explicitly requested
Inputs
the nearest AGENTS.md
package.json
eslint.config.* or .eslintrc*
tsconfig.json when TypeScript or type-aware rules are involved
Workflow
Detect ownership first:
existing ESLint config
package manager and workspace layout
framework packages such as React, Next.js, Vue, or plain TypeScript
Keep ESLint as the semantic lint owner for JS and TS files when the repo needs rich plugin ecosystems or framework-specific rules.
Prefer checked-in local devDependencies over global installs so CI and local runs match.
Add narrow scripts to package.json, for example:
lint: eslint .
lint:fix: eslint . --fix
Scope auto-fix runs before broad rewrites:
fix a bounded folder or glob first
rerun the linter
rerun the frontend build or tests if the repo has them
If the repo wants type-aware rules, verify the target files are covered by the intended tsconfig.json before enabling heavier rules.
Do not hide noise by mass-disabling rules. Fix code, narrow scope, or phase severity deliberately.