Claude Skill

dotnet-stylelint

Use Stylelint in .NET repositories that ship CSS, SCSS, or other stylesheet assets alongside web frontends. Use when a repo needs a dedicated CLI lint gate for selectors, properties, duplicate styles, naming conventions, or design-system rule enforcement.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download postpartum-genushyacinthus29-dotnet-skills-skills_dotnet-stylelint-bfa4ebd.zip · 3 KB
Part of postpartum-genushyacinthus29/dotnet-skills — 80 skills

Install

skills CLI npx skills add https://github.com/Postpartum-genushyacinthus29/dotnet-skills/tree/main/skills/dotnet-stylelint
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install postpartum-genushyacinthus29-dotnet-skills@llmmart
Git git clone https://github.com/Postpartum-genushyacinthus29/dotnet-skills.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole postpartum-genushyacinthus29/dotnet-skills collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

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 dotnet-eslint or dotnet-biome
  • runtime accessibility, performance, SEO, or header checks; route that to dotnet-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

  1. Confirm what Stylelint should own:
    • plain CSS only
    • CSS plus SCSS
    • embedded styles in HTML, Markdown, or framework files
  2. Prefer repo-local installation and checked-in config.
  3. Start from a known shared config such as stylelint-config-standard, then add syntax-specific packages only when the repo truly needs them.
  4. Add repeatable scripts to package.json, for example:
    • stylelint "**/*.{css,scss}"
    • stylelint "**/*.{css,scss}" --fix
  5. Keep ignore patterns explicit so build output, vendored assets, and generated CSS do not pollute the signal.
  6. Treat autofix as controlled cleanup:
    • run on a bounded scope first
    • inspect the diff
    • rerun the frontend build if the repo compiles styles
  7. Use Stylelint for semantic CSS and selector policy, not as a replacement for site-level audits.

Bootstrap When Missing

  1. Detect current state:
    • rg --files -g 'package.json' -g 'stylelint.config.*' -g '.stylelintrc*'
    • rg -n '"stylelint"|"stylelint-config-" --glob 'package.json' .
  2. Prefer a repo-local install:
    • npm install --save-dev stylelint stylelint-config-standard
  3. Add syntax packages only when the repo needs them for SCSS or embedded styles.
  4. Create or refine stylelint.config.js, stylelint.config.mjs, or the existing config format.
  5. Add repeatable commands to AGENTS.md and package.json, then verify with:
    • npx stylelint "**/*.{css,scss}"
    • npx stylelint "**/*.{css,scss}" --fix
  6. Return status: configured if Stylelint is now wired and repeatable, or status: improved if the existing baseline was tightened.
  7. Return status: not_applicable only when another documented tool already owns stylesheet linting and migration is not requested.

Handle Failures

  • Unknown rule usually means the config expects a plugin or a different Stylelint major version.
  • Unknown word on SCSS, Vue, or mixed-content files usually means the repo needs the matching custom syntax package instead of plain CSS parsing.
  • Massive autofix churn usually means generated assets or third-party CSS slipped into the lint target.
  • Design-system rule noise should be handled by tuning the checked-in config, not by skipping the linter entirely.

Current 17.5 Guidance

  • Stylelint 17.5.0 deprecates the *syntax rule options under declaration-property-value-no-unknown. If the repo still relies on those options, move the compatibility into customSyntax or parser selection instead of extending deprecated rule config.
  • media-feature-name-value-no-unknown now supports ignoreMediaFeatureNameValues. Use it when the design system or platform layer intentionally allows non-standard media feature values and you want that exception recorded explicitly.
  • Stylelint 17.5.0 fixed node_modules ignore behavior in Node.js API flows that pass codeFilename. Keep repo ignores focused on generated or vendored assets instead of compensating for the old bug with over-broad globs.
  • Selector and deprecated-keyword false-positive fixes landed in no-descending-specificity, no-duplicate-selectors, and declaration-property-value-keyword-no-deprecated. Re-run the repo baseline before preserving stale disables or waivers.

Official Sources

Deliver

  • explicit stylesheet lint ownership
  • checked-in config and repeatable commands
  • clear scope boundaries for CSS, SCSS, and generated assets

Validate

  • the lint target matches the repo's real stylesheet sources
  • ignores exclude generated or vendored assets
  • Stylelint ownership does not conflict with Biome without an explicit plan
  • fixes were verified against the repo's stylesheet build flow when one exists

Ralph Loop

  1. Plan: analyze current state, target outcome, constraints, and risks.
  2. Execute one step and produce a concrete delta.
  3. Review the result and capture findings.
  4. Apply fixes in small batches and rerun checks.
  5. Update the plan after each iteration.
  6. Repeat until outcomes are acceptable.
  7. If a dependency is missing, bootstrap it or return status: not_applicable with a reason.

Required Result Format

  • status: complete | clean | improved | configured | not_applicable | blocked
  • plan: concise plan and current step
  • actions_taken: concrete changes made
  • verification: commands, checks, or review evidence
  • remaining: unresolved items or none

Example Requests

  • "Add Stylelint for the SCSS in this ASP.NET Core app."
  • "Block duplicate selectors and invalid CSS in CI."
  • "Fix the current Stylelint violations without touching generated CSS."

References

  • release-notes.md - Current 17.5.0 release changes that matter for repo config, rule tuning, and Node API integrations
Files (dotnet-skills)
  • references
    • release-notes.md 1.5 KB
      # Stylelint 17.5.0 Notes
      
      Use this note when a repo already has Stylelint wired and you need to refresh config or validation behavior after the `17.5.0` release.
      
      ## What changed that matters for repository maintenance
      
      - `declaration-property-value-no-unknown` deprecates its `*syntax` rule options.
      - `media-feature-name-value-no-unknown` adds `ignoreMediaFeatureNameValues`.
      - The Node.js API now correctly ignores `node_modules` again when `codeFilename` is used.
      - Selector and declaration fixes reduce false positives and false negatives in:
        - `no-descending-specificity`
        - `no-duplicate-selectors`
        - `declaration-property-value-keyword-no-deprecated`
        - `declaration-property-value-no-unknown`
        - `no-invalid-position-declaration`
        - `property-no-unknown`
      
      ## Practical repo guidance
      
      1. Check whether the config still uses deprecated `*syntax` options.
      2. Replace those options with explicit syntax handling via `customSyntax` or the repo's selected syntax package.
      3. If the repo uses `media-feature-name-value-no-unknown` and intentionally permits platform-specific values, document them via `ignoreMediaFeatureNameValues`.
      4. Re-run the lint baseline and remove stale ignores or waivers that only existed to compensate for older false positives.
      5. If the repo drives Stylelint through the Node.js API, drop any workaround ignore logic that was only there because `codeFilename` used to bypass the default `node_modules` ignore behavior.
      
      ## Source
      
      - [Stylelint 17.5.0 release notes](https://github.com/stylelint/stylelint/releases/tag/17.5.0)
      
  • SKILL.md 6.1 KB
    ---
    name: dotnet-stylelint
    version: "1.1.0"
    category: "Code Quality"
    description: "Use Stylelint in .NET repositories that ship CSS, SCSS, or other stylesheet assets alongside web frontends. Use when a repo needs a dedicated CLI lint gate for selectors, properties, duplicate styles, naming conventions, or design-system rule enforcement."
    compatibility: "Requires a .NET repository with stylesheet assets such as `wwwroot/`, `ClientApp/`, `src/`, or other frontend folders managed with Node tooling."
    ---
    
    # 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 `dotnet-eslint` or `dotnet-biome`
    - runtime accessibility, performance, SEO, or header checks; route that to `dotnet-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
    
    1. Confirm what Stylelint should own:
       - plain CSS only
       - CSS plus SCSS
       - embedded styles in HTML, Markdown, or framework files
    2. Prefer repo-local installation and checked-in config.
    3. Start from a known shared config such as `stylelint-config-standard`, then add syntax-specific packages only when the repo truly needs them.
    4. Add repeatable scripts to `package.json`, for example:
       - `stylelint "**/*.{css,scss}"`
       - `stylelint "**/*.{css,scss}" --fix`
    5. Keep ignore patterns explicit so build output, vendored assets, and generated CSS do not pollute the signal.
    6. Treat autofix as controlled cleanup:
       - run on a bounded scope first
       - inspect the diff
       - rerun the frontend build if the repo compiles styles
    7. Use Stylelint for semantic CSS and selector policy, not as a replacement for site-level audits.
    
    ## Bootstrap When Missing
    
    1. Detect current state:
       - `rg --files -g 'package.json' -g 'stylelint.config.*' -g '.stylelintrc*'`
       - `rg -n '"stylelint"|"stylelint-config-" --glob 'package.json' .`
    2. Prefer a repo-local install:
       - `npm install --save-dev stylelint stylelint-config-standard`
    3. Add syntax packages only when the repo needs them for SCSS or embedded styles.
    4. Create or refine `stylelint.config.js`, `stylelint.config.mjs`, or the existing config format.
    5. Add repeatable commands to `AGENTS.md` and `package.json`, then verify with:
       - `npx stylelint "**/*.{css,scss}"`
       - `npx stylelint "**/*.{css,scss}" --fix`
    6. Return `status: configured` if Stylelint is now wired and repeatable, or `status: improved` if the existing baseline was tightened.
    7. Return `status: not_applicable` only when another documented tool already owns stylesheet linting and migration is not requested.
    
    ## Handle Failures
    
    - `Unknown rule` usually means the config expects a plugin or a different Stylelint major version.
    - `Unknown word` on SCSS, Vue, or mixed-content files usually means the repo needs the matching custom syntax package instead of plain CSS parsing.
    - Massive autofix churn usually means generated assets or third-party CSS slipped into the lint target.
    - Design-system rule noise should be handled by tuning the checked-in config, not by skipping the linter entirely.
    
    ## Current 17.5 Guidance
    
    - Stylelint `17.5.0` deprecates the `*syntax` rule options under `declaration-property-value-no-unknown`. If the repo still relies on those options, move the compatibility into `customSyntax` or parser selection instead of extending deprecated rule config.
    - `media-feature-name-value-no-unknown` now supports `ignoreMediaFeatureNameValues`. Use it when the design system or platform layer intentionally allows non-standard media feature values and you want that exception recorded explicitly.
    - Stylelint `17.5.0` fixed `node_modules` ignore behavior in Node.js API flows that pass `codeFilename`. Keep repo ignores focused on generated or vendored assets instead of compensating for the old bug with over-broad globs.
    - Selector and deprecated-keyword false-positive fixes landed in `no-descending-specificity`, `no-duplicate-selectors`, and `declaration-property-value-keyword-no-deprecated`. Re-run the repo baseline before preserving stale disables or waivers.
    
    ## Official Sources
    
    - [Stylelint 17.5.0 release notes](https://github.com/stylelint/stylelint/releases/tag/17.5.0)
    - `references/release-notes.md`
    
    ## Deliver
    
    - explicit stylesheet lint ownership
    - checked-in config and repeatable commands
    - clear scope boundaries for CSS, SCSS, and generated assets
    
    ## Validate
    
    - the lint target matches the repo's real stylesheet sources
    - ignores exclude generated or vendored assets
    - Stylelint ownership does not conflict with Biome without an explicit plan
    - fixes were verified against the repo's stylesheet build flow when one exists
    
    ## Ralph Loop
    
    1. Plan: analyze current state, target outcome, constraints, and risks.
    2. Execute one step and produce a concrete delta.
    3. Review the result and capture findings.
    4. Apply fixes in small batches and rerun checks.
    5. Update the plan after each iteration.
    6. Repeat until outcomes are acceptable.
    7. If a dependency is missing, bootstrap it or return `status: not_applicable` with a reason.
    
    ### Required Result Format
    
    - `status`: `complete` | `clean` | `improved` | `configured` | `not_applicable` | `blocked`
    - `plan`: concise plan and current step
    - `actions_taken`: concrete changes made
    - `verification`: commands, checks, or review evidence
    - `remaining`: unresolved items or `none`
    
    ## Example Requests
    
    - "Add Stylelint for the SCSS in this ASP.NET Core app."
    - "Block duplicate selectors and invalid CSS in CI."
    - "Fix the current Stylelint violations without touching generated CSS."
    
    ## References
    
    - [release-notes.md](references/release-notes.md) - Current 17.5.0 release changes that matter for repo config, rule tuning, and Node API integrations
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related