Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
forcedotcom avatar

Validating Slds

  • 932 installs
  • 787 repo stars
  • Updated August 5, 2026
  • forcedotcom/sf-skills

validating-slds is a Salesforce Lightning Web Component skill that audits SLDS compliance, accessibility attributes, and CSS theming hooks to produce a scored quality report for developers who need component readiness ch

About

validating-slds is a Salesforce-focused agent skill that audits Lightning Web Components for SLDS compliance and returns a scored quality report. The skill runs the SLDS linter, analyzes CSS for theming hook usage and pairing, checks HTML for accessibility attributes, and aggregates findings into category scores with an overall grade. Developers reach for validating-slds when asked to score a component, produce an SLDS scorecard, audit compliance, or evaluate whether an LWC is ready to ship. Trigger phrases include "rate my component", "audit SLDS compliance", and "review my component before code review". Output includes a structured quality report suitable for manual review gating before submission.

  • Runs the official SLDS linter plus supplementary static analysis for CSS theming hooks, HTML accessibility attributes, a
  • Produces a scored quality report with category breakdowns and an overall production-readiness grade.
  • Serves as a required manual review gate before code submission.
  • Valid for single components, full projects, or before/after change comparisons.
  • Explicitly not for fixing violations or building new components.

Validating Slds by the numbers

  • 932 all-time installs (skills.sh)
  • Ranked #145 of 1,352 Code Review & Quality skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/forcedotcom/sf-skills --skill validating-slds

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs932
repo stars787
Last updatedAugust 5, 2026
Repositoryforcedotcom/sf-skills

How do you score SLDS compliance in Lightning Web Components?

Automatically audit Lightning Web Components for SLDS compliance and receive a scored quality report with a manual review gate.

Who is it for?

Salesforce developers shipping Lightning Web Components who need a structured SLDS audit before code review or AppExchange submission.

Skip if: Teams building non-Salesforce frontends or backends where SLDS rules and LWC file structures do not apply.

When should I use this skill?

A developer asks to score, rate, audit, or evaluate SLDS compliance or component quality on an LWC before review or submission.

What you get

Scored SLDS quality report with category grades, linter findings, CSS theming analysis, and accessibility checks.

  • scored SLDS quality report
  • categorized linter findings

Files

SKILL.mdMarkdownGitHub ↗

SLDS Quality Audit

Audit Lightning Web Components for SLDS compliance and produce an automated scorecard plus a required manual review gate. Combines SLDS linter output with supplementary static analysis to catch what the linter misses.

Scope

Also valid for: auditing SLDS compliance across a project or component set, and before/after quality comparison after making changes.

Not for:

  • Fixing linter violations — use uplifting-components-to-slds2 instead
  • Building new components — use applying-slds instead
  • Just running the linter — run npx @salesforce-ux/slds-linter@latest lint . directly
  • Full WCAG accessibility audit — this skill checks attribute presence only (labels, alt text, focus indicators), not contrast ratios, keyboard flows, or screen reader behavior
  • Framework-specific template auditing beyond .css, .html, and .js files — JSX/TSX/Vue/Svelte outputs need additional manual review

---

Quality Validation Process

1. Run SLDS Linter     → Collect violation counts (linter's job)
2. Run Analyze Script  → Check what linter doesn't cover (supplementary)
3. Agent Review        → Required manual review gate
4. Score & Grade       → Compute automated score + final recommendation
5. Generate Report     → Produce formatted scorecard

Step 1: Run SLDS Linter

Run the linter to collect baseline violation data:

npx @salesforce-ux/slds-linter@latest lint <component-path> 2>&1

Count violations by rule. These feed directly into the Linter Compliance score:

RuleImpact
slds/class-overrideBreaks theming, dark mode
slds/lwc-token-to-slds-hookSLDS 1 technical debt
slds/no-hardcoded-valuesBreaks theming, accessibility

Linter Compliance Score = 100 - (total_violations × 10), minimum 0.

If the linter is unavailable (no Node.js, no network access, CI sandbox restrictions): skip this step, note "Linter not run" in the report header, mark Linter Compliance as N/A, and compute the Overall score using the remaining 4 categories renormalized to 100%:

Overall (linter unavailable) = (Theming × 0.29) + (Accessibility × 0.29)
                              + (CodeQuality × 0.21) + (ComponentUsage × 0.21)

Step 2: Run Supplementary Analysis

Run the analyze script to catch issues the linter doesn't cover. The bundled analyzer scans .css, .html, and .js files only:

node scripts/analyze-quality.cjs <component-path>

The script outputs JSON with findings organized by severity. It checks:

CSS Checks (linter-complementary)

CheckWhat It CatchesSeverity
Missing fallbacksvar(--slds-g-*) without a fallback valueCritical
Invented hooks (T051)--slds-g-* tokens not found in hooks-index.json (requires --hooks-index)Critical
Hook pairingBackground hooks without matching foreground hooksWarning
!importantSpecificity overridesWarning
Magic pixel valuesHardcoded px not using spacing hooksWarning
High z-indexz-index values > 99Warning
Outline removaloutline: none without alternative focus styleWarning

JS Checks

CheckWhat It CatchesSeverity
Inline style assignment.style.*= direct property assignmentWarning
SLDS class manipulationDynamic .classList.add('slds-*') manipulationWarning

HTML Checks

CheckWhat It CatchesSeverity
LBC input labels<lightning-input> without label attributeCritical
Icon alt text<lightning-icon> without alternative-textCritical
Image alt text<img> without altCritical
Heading hierarchySkipped heading levels (h2 to h4)Warning
Positive tabindextabindex values other than 0 or -1Warning
Clickable divs<div onclick> instead of <button>Warning
Inline stylesstyle="..." attributesWarning
Native elements<input>, <button>, <select> where LBC alternatives existWarning

Hook Pairing Validation

The script checks that background/foreground hooks are semantically paired:

surface-* backgrounds     → on-surface-* text
surface-container-* bg    → on-surface-* text
accent-* backgrounds      → on-accent-* text
accent-container-* bg     → on-accent-* text
Limitation: Hook pairing is checked at the file level, not per-selector. A file with surface-1 in .classA and on-accent-1 in .classB would pass because both surface and accent families are present. Review pairing correctness per-selector during manual review (Step 3).

Invented Hook Detection (T051)

The script cross-references every --slds-g-* token in CSS against hooks-index.json. Any hook not found in metadata is flagged as critical — this catches the most common agent mistake of inventing hooks from naming patterns.

Step 3: Agent Manual Review

These checks require understanding the component's purpose and cannot be automated reliably. Review each and classify findings as either:

  • Blocking — incorrect blueprint structure, missing required states, or semantic/interaction issues that make the component not production-ready
  • Advisory — worthwhile improvements that do not block shipping on their own
Review AreaWhat to Look For
Loading statesDoes the component show a spinner or skeleton when fetching data?
Error statesAre errors surfaced to the user with actionable messages?
Empty statesIs there a meaningful empty state when no data exists?
Disabled statesDo interactive elements visually and functionally handle disabled?
Semantic HTMLAre <nav>, <article>, <section> used where appropriate?
SLDS blueprint complianceDo cards, modals, forms follow SLDS blueprint structure?
Manual review findings are not automated, but they do affect the final recommendation. Do not report an automated grade as the only verdict.

Step 4: Calculate Automated Scores and Final Recommendation

Component Complexity

Before scoring, classify the component to give the score context:

ComplexityCriteriaReport Note
Small1-2 files, < 100 total linesScore is high-confidence (small surface area)
Medium3-6 files, 100-500 total linesScore reflects typical component
Large7+ files, 500+ total linesScore reflects absolute issue count — even well-built large components may score lower

Include the complexity classification in the report header. This prevents misreading a "B" on a 1000-line component vs. a "B" on a 20-line component.

Automated Scoring Formula

Category Score = 100 - (critical_issues × 10) - (warnings × 3) - (info × 1)
Minimum score: 0

Categories and Weights

CategoryWeightSource
Linter Compliance30%SLDS linter output (Step 1)
Theming20%Script: fallbacks, hook pairing (Step 2)
Accessibility20%Script: labels, alt text, focus (Step 2)
Code Quality15%Script: !important, inline styles, z-index (Step 2)
Component Usage15%Script: native elements (Step 2) plus manual semantic/blueprint review (Step 3)

Automated Overall Score

Overall = (Linter × 0.30) + (Theming × 0.20) + (Accessibility × 0.20)
        + (CodeQuality × 0.15) + (ComponentUsage × 0.15)

Automated Grade Thresholds

ScoreGradeMeaning
90-100AExcellent automated score
80-89BGood automated score
70-79CAcceptable automated score
60-69DWeak automated score
0-59FFailing automated score

Manual Review Gate

After computing the automated score, apply the manual review outcome:

GateWhen to use itEffect on final recommendation
PassNo manual findingsFinal recommendation can follow the automated score
AdvisoryOnly non-blocking manual findingsFinal recommendation can be "Ready with follow-ups" at best
BlockingOne or more blocking manual findingsFinal recommendation is not ready for production, regardless of automated grade

Final Recommendation Rules

Use both the automated score and the manual review gate:

Final RecommendationConditions
Ready for productionAutomated grade A/B, no critical findings, manual gate = Pass
Ready with follow-upsAutomated grade A/B, no critical findings, manual gate = Advisory
Needs workAny critical findings, automated grade C/D, or manual gate = Blocking
FailingAutomated grade F

Step 5: Generate Quality Report

Use the template in [report-format.md](references/report-format.md) to produce the final report. Default to the compact format for initial output and expand sections on request.

The report includes:

  • Executive summary with automated grade and final recommendation
  • Manual review gate outcome (Pass, Advisory, or Blocking)
  • Scores by category with visual indicators
  • Detailed findings organized by severity
  • Specific code locations and recommendations
  • Checklist of required actions

---

Quick Validation Mode

For a rapid quality check without full analysis:

1. Run linter: npx @salesforce-ux/slds-linter@latest lint <path> 2. Count violations by type 3. Report summary only

Quick Quality Check: <component-name>
─────────────────────────────────────
Linter Violations:
  • Class Override:     0
  • Deprecated Tokens:  3
  • Hardcoded Values:   5

Quick Automated Grade: C (estimated)
Run full validation for detailed report.

---

Edge Cases and False Positives

SituationGuidance
Headless components (JS-only, no HTML)Skip HTML checks; score only CSS + linter categories
Wrapper/container componentsMay legitimately have minimal CSS; don't penalize low hook usage
Intentional native elements<button> inside custom SLDS blueprints is correct; suppress C002 if inside an slds-* blueprint structure
Components outside LEXLWR/Experience Cloud components may not use Lightning Base Components; note context in report
Test/demo componentsLower the bar — note in report but don't block on warnings

If a check produces a false positive, note it in the report as "suppressed" with justification rather than silently dropping it.

---

References

  • [Quality Checks](references/quality-checks.md) - Complete list of all quality checks with detection patterns
  • [Report Format](references/report-format.md) - Quality report template and formatting guide
  • [Analyze Script](scripts/analyze-quality.cjs) - Automated analysis for linter-complementary checks
  • uplifting-components-to-slds2 skill - How to fix linter violations
  • applying-slds skill - Guide for building new components with correct patterns

Related skills

How it compares

Choose validating-slds over generic frontend linters when the target is Salesforce LWC with SLDS-specific theming hooks and scorecard-style grading.

FAQ

What does validating-slds check in an LWC?

validating-slds runs the SLDS linter, reviews CSS for theming hook usage and pairing, inspects HTML accessibility attributes, and rolls findings into category scores plus an overall grade for manual review.

When should developers run validating-slds?

validating-slds fits pre-code-review and pre-submission checks when a developer wants an SLDS scorecard, quality report, or readiness audit on a Lightning Web Component.

Code Review & Qualitytestingintegrations

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.