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.
SkillScore86Maintained
Automatic
◆Frontend / UI pack
Last verified 8/19/2026
What it changes
Passed 16 of 19 test cases with the skill, and 10 of 19 without it.
Without skill50%
With skill86%
Checks it passed that the model alone missed
returns status: improved
returns status: configured
returns status: not_applicable
and 5 more in the full report
8 fixed11 passed either way3 still failing0 broke
Pass-rate lift
+36 pp
Tokens
+75%
Agent turns
0%
Response time
-23%
Model gemini-3.6-flashMeasured 8/19/2026v119 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
We just completed setting up stylesheet linting from scratch in a repository that previously had no linter config, installing standard configs and adding npm scripts. Which status value must be reported in the output summary? Format your output with status, plan, actions_taken, verification, and remaining fields.
What was checked, without and with the skill
Checked
Without skill
With skill
returns status: configured
Missed
Passed
case-20 · 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.md114 lines2 files
Stylelint for Stylesheets in .NET Repositories
Trigger On
the repo has stylelint.config.*, .stylelintrc*, or CSS and SCSS assets under frontend folders
the user asks for CSS linting, duplicate style cleanup, naming convention enforcement, or design-system guardrails
the repo needs a stylesheet gate beyond formatting alone
Do Not Use For
JavaScript or TypeScript ownership; route that to eslint or biome
runtime accessibility, performance, SEO, or header checks; route that to webhint
repos that intentionally use only Biome for CSS linting and do not want a separate stylesheet linter
Inputs
the nearest AGENTS.md
package.json
stylelint.config.* or .stylelintrc*
the stylesheet file types in scope: CSS, SCSS, Less, embedded styles, or generated output
Workflow
Confirm what Stylelint should own:
plain CSS only
CSS plus SCSS
embedded styles in HTML, Markdown, or framework files
Prefer repo-local installation and checked-in config.
Start from a known shared config such as stylelint-config-standard, then add syntax-specific packages only when the repo truly needs them.
Add repeatable scripts to package.json, for example:
stylelint "**/*.{css,scss}"
stylelint "**/*.{css,scss}" --fix
Keep ignore patterns explicit so build output, vendored assets, and generated CSS do not pollute the signal.
Treat autofix as controlled cleanup:
run on a bounded scope first
inspect the diff
rerun the frontend build if the repo compiles styles
Use Stylelint for semantic CSS and selector policy, not as a replacement for site-level audits.