sonarjs
SonarJS Rules for Frontend Assets in .NET Repositories
Trigger On
- the repo already uses SonarQube, SonarCloud, or
eslint-plugin-sonarjs - the user asks for frontend code smells, cognitive complexity limits, or deeper bug-risk rules beyond base ESLint
- maintainability and reliability findings on JS or TS code should become a review or CI gate
Do Not Use For
- repos that want only a lightweight base lint setup with no extra smell or complexity rules
- teams that reject SonarQube, SonarCloud, or source-available SonarJS-derived tooling as a default gate
- cases where the problem is runtime page quality rather than source-level maintainability
Inputs
- the nearest
AGENTS.md package.json- existing ESLint config
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