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

Workflow

1. Detect ownership first:

- existing ESLint config - package manager and workspace layout - framework packages such as React, Next.js, Vue, or plain TypeScript

1. Keep ESLint as the semantic lint owner for JS and TS files when the repo needs rich plugin ecosystems or framework-specific rules.
2. Prefer checked-in local devDependencies over global installs so CI and local runs match.
3. Add narrow scripts to package.json, for example:

- lint: eslint . - lint:fix: eslint . --fix

1. 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

1. If the repo wants type-aware rules, verify the target files are covered by the intended tsconfig.json before enabling heavier rules.
2. Do not hide noise by mass-disabling rules. Fix code, narrow scope, or phase severity deliberately.

Deliver

• explicit ESLint ownership for JS or TS frontend assets
• checked-in commands for lint and lint:fix
• config decisions that match the repo's real frontend stack

Validate

• ESLint is running from repo-local dependencies
• rule ownership is not ambiguous versus Biome or other linters
• the chosen globs match the real frontend folders
• fixes were verified with the repo's normal frontend build or test pass when available

Related skills

Related agents