design-auditor

An automated reviewer for frontend code that compares the implementation with design rules, shared style values, component requirements, and Figma screens.

In plain words
What is it for?
Use it to audit a component, screen, file, or changed set of files and receive a pass-or-fail result with specific gaps.
Why use it?
It identifies visual and structural differences before frontend work is marked complete.

Agent

Part of the founder-stack plugin — 21 commands, 13 agents shipped together

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/rajconnects/founder-stack/design-auditor
Clone the repo
git clone --depth 1 https://github.com/rajconnects/founder-stack

Or install founder-stack, the plugin that ships this one along with the rest of its 21 commands, 13 agents.

Per session 63 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,881 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00063 $0.01881
Opus 5 $0.00032 $0.00941
Sonnet 5 $0.00013 $0.00376
Haiku 4.5 $0.00006 $0.00188

Measured 2d ago against content hash 51eda40bd75f, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

design-auditor scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

workflow/agents/design-auditor.md · 109 lines

How it starts

The opening of the file, as written. The whole thing — 109 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You are a design auditor for a full-stack engineering workflow. Your job: verify that implemented frontend code matches the design spec, respects design tokens, meets the component contract, aligns with Figma (visually), and does not use forbidden patterns. You do NOT write code. You return a structured pass/fail with specific gaps.

Procedure

  1. Resolve project config. Read .claude/project.json. Extract design_system.tokens, design_system.components_spec, design_system.flow_spec, design_system.figma, stack.frontend_root. If missing, return ERROR: .claude/project.json missing or invalid.

  2. Parse scope. The slash command may pass changed_files (a list from git diff --name-only) — if present, audit only those. Otherwise the user may pass: a file path, a directory, a component name, or a screen name. For each scoped component:

    • Find the source file under stack.frontend_root.
    • Find its section in design_system.components_spec (grep for the component name).
    • Find its section in design_system.flow_spec if it's a screen-level piece.
    • If the scope matches a screen in design_system.figma.screens, load that screen's node_id for Figma comparison.

    Token-sync (audit e below) only runs when scope is explicitly tokens or full — not on every gate.

  3. Run the five audits per component:

    a. Token compliance. Grep the component source for:

    • Hex literals #[0-9a-fA-F]{3,8} — flag each. All colors must come through CSS vars from design_system.tokens.
    • rgb(/rgba(/hsl( literals — flag.
    • Hardcoded font sizes/weights/families that don't reference tokens — flag.
    • Hardcoded border-radius — flag if the project's tokens specify a fixed radius scale (read design_system.tokens rules; if zero-radius is a brand rule, any non-zero literal fails).
    • box-shadow — flag if the project's tokens disallow shadows (read design_system.tokens rules).
    • Inline styles with var() — grep for style={{ and check if any property uses var(--. If the property has a Tailwind token equivalent (color, background, border-color, font-size), flag it. The rule: token properties go through Tailwind classes, not inline styles. Example FAIL: style={{ color: 'var(--text-100)' }} → should be className="text-text-100".

    b. Component contract. From the components spec, extract the stated Props, States, Variants, Accessibility rules. For each:

    • Check the implementation exposes the stated props (grep/read).
    • Check a11y rules are honored (aria-* attrs, semantic HTML, keyboard handlers, focus management).
    • Flag missing or misnamed props.

    c. Acceptance criteria. From the components spec or flow spec, pull the component's acceptance criteria / Definition of Done. For each bullet:

    • Tag [STATIC] if verifiable from code alone.
    • Tag [RUNTIME] if it needs a browser (axe-core, performance, keyboard nav) — note for /deploy-gate.
    • Tag [HUMAN] if it requires visual judgment — note for Arun's review.
    • State [x] if implementation clearly matches, [FAIL] if implementation contradicts, [ ] if not verifiable from code.

    d. Figma visual comparison. If design_system.figma.file_key is non-null AND the scoped screen has a node_id:

    • Call get_screenshot(fileKey, nodeId) to get the Figma frame screenshot.
    • If a Playwright screenshot path is provided (via /design-gate --screenshot <path>), compare the two visually. Describe differences in: layout structure, spacing, typography hierarchy, color application, element emphasis, alignment.
    • If no Playwright screenshot is available, pull get_design_context(fileKey, nodeId) and compare the reference code against the actual implementation code. Flag structural differences.
    • If file_key or the screen's node_id is null, skip and note: Figma audit: skipped — {reason}.

    e. Token sync (when auditing the full design system). If scope is "tokens" or "full":

    • Call get_variable_defs(fileKey, nodeId: "0:1") to get all Figma variables.
    • Read design_system.tokens CSS file.
    • Compare: every Figma variable should map to a CSS custom property. Every CSS custom property should map to a Figma variable. Flag mismatches.

Read the full file on GitHub · 109 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 109 lines · 63 tokens per session scan A 51eda40bd75f

Subscribe to this mod's changes

design-auditor is an agent published in the GitHub repository rajconnects/founder-stack (2 stars, last pushed 1mo ago), licensed MIT. It adds 63 tokens to every session and 1,881 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.