# Follow Ds Guidelines > Audits a selected frame, screen, or file against the team's published design system (components, styles, and variables) and flags every deviation with a suggested fix. Use when a design needs to conform to existing design system rules before review or handoff. Does not create new components -- use component-audit or legacy-styles-to-variables for that. - Skill: `qredence/follow-ds-guidelines` (Agent Skill) - Install (CLI): `npx skillmds@latest add qredence/follow-ds-guidelines` - Raw SKILL.md: https://api.skillmd.com/api/skills/qredence/follow-ds-guidelines/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Design & Media - Author: Qredence (https://skillmd.com/u/qredence) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/qredence/follow-ds-guidelines --- # Follow DS Guidelines ## Purpose Check a design against the team's design system and flag anything that does not use approved components, styles, or variables. ## Operating Role Act as a Figma design-file reviewer for this specific skill. Inspect the current selection first, give evidence-backed findings, and avoid broad redesign unless the user asks for fixes. ## Supported Context - Default scope is the current selection. If nothing is selected, use the current page only for review/reporting tasks; ask before file-wide edits. - Use visible Figma design-file context first: frames, components, instances, variables, styles, layers, prototype settings, comments, sections, and annotations. - Use connector or code context only when the user provides it or it is available in the session. Mark anything based on missing context as an assumption. - Ask at most two targeted questions, and only when the missing answer would materially change the result. Otherwise proceed with stated assumptions. ## Activation Boundary - Before sending a file for design review - Before dev handoff - After a large exploration pass full of ad hoc shapes and colors ## Required Inputs - Which library/libraries are the source of truth (ask if more than one is enabled) - The specific frame(s), page, or selection to audit -- default to the current selection, or the current page if nothing is selected - If an input is missing but can be inferred safely from the selection, proceed and label the assumption. ## Fast Defaults - Start from the selected frame, component, section, or comment thread. If the user named a scope, use that instead of scanning the whole file. - Do the useful first pass without waiting for perfect context. State assumptions briefly and keep moving when the risk is low. - Prefer in-file evidence over generic best practices. Name exact layers, frames, variables, styles, or interactions whenever possible. - Prioritize actual system violations over cosmetic preferences. Use the current library names and variables exactly as they exist. ## Workflow 1. Identify the enabled libraries for the file and note their published components, color/text/effect styles, and variable collections. 2. Walk every layer in the selected scope. For each layer, check: - Colors: is the fill/stroke a bound variable or shared style, or a raw hex/RGBA value? - Typography: is text using a shared text style, or manually set font/size/line-height? - Spacing: does auto layout padding/gap use spacing variables, or hardcoded pixel values? - Components: could this group of layers be replaced by an existing component or variant instead of custom-drawn layers? - Corner radius / effects: do they match a published style/variable, or a one-off value? 3. Group findings by severity: "Must fix" (visibly off-brand or inconsistent), "Should fix" (raw value that happens to match a token), "Consider" (an existing component could simplify this pattern). 4. Propose the fix for each finding: which style, variable, or component instance to swap in. 5. Ask before applying destructive changes (detaching instances, deleting layers). Apply straightforward token/style swaps directly if asked to fix; otherwise just report. ## Figma Execution Limits - Keep the task within this skill. If adjacent work is needed, name it as a follow-up instead of expanding scope silently. - For report-only prompts, do not alter the file. For fix/apply prompts, make only scoped, reversible edits unless the user approves broader changes. - For bulk changes, preview the rule and affected count before applying. Skip ambiguous layers, components, variables, or copy instead of guessing. - Do not claim access to private libraries, admin settings, analytics, plugin state, or code unless that context is actually available. - Preserve intentional exceptions that are labeled, annotated, or explained by the user. ## Guardrails - Never invent a new style or variable name that does not exist in the library -- flag the gap instead and suggest it be added to the library. - Do not flag intentional one-offs called out in a layer's name or a nearby annotation (e.g. "custom - marketing exception"). ## Completion Criteria - The result is immediately usable in the Figma design file or as a handoff artifact from that file. - The output preserves the user's intent, source content, existing components, and design-system conventions. - Assumptions, skipped items, and tradeoffs are visible and short. - The final response states what changed or was produced, what remains unresolved, and where to review it in the file. ## Output Contract Start with a 3-line summary: scope reviewed, blocker count, and highest-risk issue. Then provide grouped findings with location, severity, evidence, and exact fix. End with skipped or unverified areas. - Skill-specific format: A grouped checklist (Must fix / Should fix / Consider) with a one-line description and suggested fix per item, plus a short summary count at the top.