design-systems-slds-apply

Generates SLDS-compliant UI code using verified blueprints, styling hooks, utility classes, and icons.

Updated Jul 2, 2026
One-click install
npx skills add https://github.com/padjei/SF_Build --skill design-systems-slds-apply-padjei
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: design-systems-slds-apply
Source: https://github.com/padjei/SF_Build/tree/main/.claude/skills/design-systems-slds-apply
Command: npx skills add https://github.com/padjei/SF_Build --skill design-systems-slds-apply-padjei

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires @salesforce-ux/slds-linter, and includes scripts (resource) and references (resource) components.

What problem does it solve? Building Salesforce Lightning Design System (SLDS) interfaces often leads to invented CSS hooks, hardcoded values, and deprecated tokens because agents guess artifact names instead of verifying them. This Skill enforces a verify-before-use workflow against real SLDS metadata so generated UI code passes the official SLDS linter. ## Core Features & Use Cases - Component Selection Hierarchy: Guides the choice between Lightning Base Components, SLDS Blueprints, styling hooks, and custom CSS across LWC, React, Vue, Angular, and vanilla HTML. - Verified Artifact Lookup: Bundled search scripts query 523 styling hooks, 1,147 utility classes, 85 blueprint YAML specs, and 1,732 icons so no invented classes or hooks reach the output. - Mandatory Validation Workflow: Runs the @salesforce-ux/slds-linter plus manual checklists covering hook fallbacks, color pairing, spacing, typography, and icon accessibility. - Use Case: When asked to build a confirmation modal in LWC, the Skill selects LightningModal, verifies the error color hooks and warning icon via search scripts, applies utility classes for spacing, and validates the result against the checklist before delivery. ## Quick Start Ask the agent to build an SLDS-styled component such as a responsive card grid with status badges and icons for your LWC or React app.

Frequently Asked Questions about design-systems-slds-apply

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I build an SLDS-compliant modal or form in LWC?▼

Check the Lightning Component Library for a Lightning Base Component first, such as LightningModal or lightning-input. If none exists, search the bundled blueprint YAMLs for the pattern, apply exact slds-* classes, and style with var(--slds-g-*) hooks that include fallback values.

Should I use Lightning Base Components or SLDS Blueprints?▼

Use Lightning Base Components when building in LWC because they handle accessibility and events automatically. Use SLDS Blueprints for React, Vue, Angular, or plain HTML, or when no matching base component exists.

How do I verify an SLDS styling hook or utility class exists?▼

Run the bundled search scripts before using any artifact: search-hooks.cjs for --slds-g-* hooks, search-utilities.cjs for slds-* classes, search-blueprints.cjs for component patterns, and search-icons.cjs for icons. Never invent names from naming patterns.

Does this skill work with React or other non-LWC frameworks?▼

Yes, SLDS Blueprints provide framework-agnostic HTML and CSS classes for React, Vue, Angular, and vanilla markup. The companion validation skill fully scans CSS, HTML, and JS files but only partially covers JSX/TSX templates, which need manual review.

Why does the SLDS linter flag my generated component?▼

The linter catches hardcoded colors or spacing, overrides of .slds-* classes, and deprecated --lwc-* tokens. Fix violations by replacing values with var(--slds-g-*, fallback) hooks and using custom my-* or c-* prefixed classes instead of overriding SLDS classes.

What are the limitations of this SLDS authoring skill?▼

It does not cover design decisions like visual hierarchy, LWC mechanics such as @wire and lifecycle, or full WCAG accessibility conformance. Those require dedicated design, LWC, and accessibility skills applied separately.