Use SonarJS-derived rules in .NET repositories that ship JavaScript or TypeScript frontends and need deeper bug-risk, code-smell, or cognitive-complexity checks than a minimal ESLint baseline. USE FOR: SonarQube, SonarCloud, or eslint-plugin-sonarjs setups; frontend code smells; cognitive complexity and deeper bug-risk rules. DO NOT USE FOR: lightweight base lint setups with no extra smell or complexity rules; teams that reject Sonar tooling. INVOKES: inspect the repository context, edit targete
SkillScore77Maintained
Automatic
◆Coding pack
Last verified 8/19/2026
What it changes
Passed 15 of 19 test cases with the skill, and 8 of 19 without it.
Without skill41%
With skill77%
Checks it passed that the model alone missed
The response status is set to not_applicable.
The status field value is strictly set to configured.
The response advises against hiding findings behind broad rule disables.
and 6 more in the full report
8 fixed9 passed either way5 still failing0 broke
Pass-rate lift
+36 pp
Tokens
+24%
Agent turns
0%
Response time
-41%
Model gemini-3.6-flashMeasured 8/19/2026v317 of 22 cases passed with skill · 19 comparable
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 8 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 8
Prompt
Our team explicitly rejects SonarQube, SonarCloud, and source-available Sonar extensions. We strictly want a standard, lightweight base ESLint setup with standard syntax rules only.
What was checked, without and with the skill
Checked
Without skill
With skill
The response refrains from installing or configuring eslint-plugin-sonarjs.
Passed
Passed
The response returns status not_applicable with an explanation of team policy alignment.
Missed
Passed
case-06 · 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.md108 linessingle file
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
any SonarQube, SonarCloud, or scanner config already present in CI
flowchart LR
A["Need Sonar-style checks in a .NET repo frontend"] --> B{"Local developer loop or existing server gate?"}
B -->|Local| C["Install eslint-plugin-sonarjs"]
C --> D["Run through the normal eslint command"]
B -->|Existing SonarQube or SonarCloud gate| E["Keep full analysis in the existing scanner pipeline"]
D --> F["Phase rules and fix code"]
E --> F
Workflow
Decide the execution path first:
local developer loop through eslint-plugin-sonarjs
server-side analysis through an already adopted SonarQube or SonarCloud pipeline
For local work, treat SonarJS as an ESLint extension rather than a standalone CLI.
Use Stylelint in .NET repositories that ship CSS, SCSS, or other stylesheet assets alongside web frontends. USE FOR: stylelint.config.*, .stylelintrc*, CSS or SCSS assets; CSS linting; duplicate style cleanup and naming-convention checks. DO NOT USE FOR: JavaScript or TypeScript lint ownership; runtime accessibility, performance, SEO, or header checks. INVOKES: inspect the repository context, edit targeted files, and run relevant build, test, lint, or validation commands when changes are made.