Como criar um design system com Claude Code: Design Tokens, Storybook e CI

Quando cinco botões viram cinquenta exceções

O problema costuma começar de forma inocente. A equipe copia um botão, muda um espaçamento para uma nova tela e cria outra cor para atender a um pedido urgente. Meses depois, foco, carregamento, estado desabilitado e mensagem de erro funcionam de maneiras diferentes. Ninguém sabe qual versão é a correta, e uma troca de cor exige procurar valores em dezenas de arquivos.

Um design system não resolve isso apenas reunindo componentes em uma galeria. Ele cria um modo repetível de alterar cores, espaçamentos, tipografia, estados, revisões e testes sem quebrar as telas do produto. Claude Code ajuda porque lê o repositório, edita arquivos relacionados, executa Storybook e testes e explica o diff. Ele não substitui decisões de produto, significado da marca nem a revisão final de acessibilidade.

Este guia percorre Design Tokens, componentes React com TypeScript, Storybook, verificações visuais e de acessibilidade na CI, limites realistas para Figma e o tamanho de tarefa que funciona melhor com Claude Code.

Para continuar o estudo, consulte gestão de Design Tokens com Claude Code, desenvolvimento em Storybook com Claude Code e acessibilidade com Claude Code.

Pontos principais

• tokens.json funciona como contrato revisável no código; Figma fornece insumos de design e revisão.
• Claude Code recebe um escopo de arquivos e executa verificações reproduzíveis. Pessoas decidem semântica, marca e aprovação.
• Em Storybook baseado em Vite, a orientação atual para 2026 é @storybook/addon-vitest com vitest --project=storybook.
• A migração deve avançar um componente por vez, evitando um diff grande demais para revisar.
• Testes automáticos de a11y detectam problemas estruturais, mas não substituem teclado, leitor de tela e julgamento de UX.

Arquitetura alvo: um contrato do token até a CI

Neste fluxo, a fonte de verdade para o código é tokens.json. Figma continua essencial para o trabalho de design, mas uma alteração que chega ao produto precisa de um contrato versionado, visível no pull request e validado pela CI.

flowchart LR
  Figma["Figma Variables"]
  Tokens["tokens.json"]
  Build["token build script"]
  CSS["CSS variables"]
  TS["TypeScript token map"]
  Components["React components"]
  Storybook["Storybook stories"]
  CI["Visual and a11y CI"]

  Figma -->|review input| Tokens
  Tokens --> Build
  Build --> CSS
  Build --> TS
  CSS --> Components
  TS --> Components
  Components --> Storybook
  Storybook --> CI

Design Tokens são decisões de design nomeadas e armazenadas como dados: cores, espaços, raios, tipografia e estados de componentes. Um componente não deveria depender diretamente de #2563eb. Um token semântico como action.background.primary registra a finalidade do valor e permite trocar a marca sem uma substituição cega em todo o projeto.

As referências primárias atuais são o formato do Design Tokens Community Group, a documentação do Claude Code, as orientações de segurança do Claude Code, o Storybook Vitest addon, os testes de acessibilidade do Storybook, os testes visuais do Storybook e a API REST do Figma.

O que delegar ao Claude Code e o que uma pessoa decide

Um pedido vago como “crie um design system” deixa decisões demais em aberto e tende a produzir um diff amplo, difícil de conferir. Um pedido limitado como “migre apenas Button, preserve a API pública, acrescente estados no Storybook e rode os testes de a11y” permite revisar e reverter a mudança.

Área de trabalho	Bom escopo para Claude Code	Decisão humana
Tokens	Levantar cores e espaços repetidos no CSS	Definir significado de marca e nomes dos tokens
Componentes	Implementar primitivas tipadas como Button, Input e Alert	Aprovar API pública e semântica do produto
Storybook	Adicionar variantes, estados e interaction stories	Escolher estados relevantes nos fluxos reais
Acessibilidade	Detectar labels ausentes, foco incorreto e violações do axe	Avaliar leitor de tela, compreensão e UX final
CI	Integrar verificações visuais e de a11y aos pull requests	Definir bloqueios e processo de exceção

Antes de pedir qualquer alteração, forneça uma regra curta de projeto. O prompt abaixo limita arquivos, exige comportamento de teclado e torna os comandos de aceitação explícitos:

Regras da tarefa de design system:
- Edite apenas src/components, src/styles, .storybook, tests, scripts e tokens.json.
- Não altere cores da marca sem listar os nomes antigos e novos dos tokens.
- Cada componente novo precisa de props TypeScript, comportamento por teclado, stories no Storybook e observações de acessibilidade.
- Execute npm run tokens:build, npm run test:storybook -- --run, npm run build-storybook e npm run test:visual antes de relatar a conclusão.
- Se o comportamento de foco mudar, inclua os passos de revisão manual.

Segurança também faz parte do design system. Não inclua tokens de acesso do Figma, tokens do npm, segredos de CI nem capturas privadas de clientes em prompts, stories ou logs. Mantenha as permissões do Claude Code restritas, confira os comandos antes de aprová-los e trate grandes atualizações de snapshots como decisões que precisam de revisão humana.

Instalação mínima com o fluxo atual do Storybook

Este exemplo pressupõe uma aplicação React e TypeScript com classes utilitárias. Ajuste os comandos ao gerenciador de pacotes e ao framework do projeto de destino.

npm install class-variance-authority clsx tailwind-merge
npx storybook@latest init
npx storybook add @storybook/addon-a11y
npx storybook add @storybook/addon-vitest
npm install -D @playwright/test concurrently http-server wait-on
npx playwright install chromium

O Vitest addon exige um framework Storybook baseado em Vite ou a integração compatível de Next.js com Vite. Para esses projetos, o comando recomendado é vitest --project=storybook. Se um projeto existente não puder adotar essa integração, o antigo @storybook/test-runner deve aparecer apenas como fallback documentado ou etapa indicada no guia oficial de migração para o Vitest addon, e não como a configuração recomendada para uma instalação nova.

Os scripts abaixo reproduzem o mesmo fluxo localmente e na CI:

{
  "scripts": {
    "tokens:build": "node scripts/build-tokens.mjs",
    "storybook": "storybook dev -p 6006",
    "build-storybook": "storybook build",
    "test:storybook": "vitest --project=storybook",
    "test:visual": "playwright test tests/button.visual.spec.ts"
  }
}

Transformar Design Tokens em contrato

Separe os tokens em três níveis. Tokens primitivos guardam os valores brutos. Tokens semânticos descrevem intenções como superfície, texto e foco. Tokens de componente ligam essas intenções a um estado específico, como o fundo do botão primário.

{
  "$schema": "https://www.designtokens.org/schemas/2025.10/format.json",
  "primitive": {
    "color": {
      "blue": {
        "50": {
          "$type": "color",
          "$value": { "colorSpace": "srgb", "components": [0.9373, 0.9647, 1], "hex": "#eff6ff" }
        },
        "600": {
          "$type": "color",
          "$value": { "colorSpace": "srgb", "components": [0.1451, 0.3882, 0.9216], "hex": "#2563eb" }
        },
        "700": {
          "$type": "color",
          "$value": { "colorSpace": "srgb", "components": [0.1137, 0.3059, 0.8471], "hex": "#1d4ed8" }
        }
      },
      "gray": {
        "50": {
          "$type": "color",
          "$value": { "colorSpace": "srgb", "components": [0.9765, 0.9804, 0.9843], "hex": "#f9fafb" }
        },
        "200": {
          "$type": "color",
          "$value": { "colorSpace": "srgb", "components": [0.898, 0.9059, 0.9216], "hex": "#e5e7eb" }
        },
        "900": {
          "$type": "color",
          "$value": { "colorSpace": "srgb", "components": [0.0667, 0.0941, 0.1529], "hex": "#111827" }
        }
      },
      "red": {
        "600": {
          "$type": "color",
          "$value": { "colorSpace": "srgb", "components": [0.8627, 0.149, 0.149], "hex": "#dc2626" }
        },
        "700": {
          "$type": "color",
          "$value": { "colorSpace": "srgb", "components": [0.7255, 0.1098, 0.1098], "hex": "#b91c1c" }
        }
      },
      "white": {
        "$type": "color",
        "$value": { "colorSpace": "srgb", "components": [1, 1, 1], "hex": "#ffffff" }
      }
    },
    "space": {
      "2": { "$type": "dimension", "$value": { "value": 0.5, "unit": "rem" } },
      "3": { "$type": "dimension", "$value": { "value": 0.75, "unit": "rem" } },
      "4": { "$type": "dimension", "$value": { "value": 1, "unit": "rem" } },
      "6": { "$type": "dimension", "$value": { "value": 1.5, "unit": "rem" } }
    },
    "radius": {
      "md": { "$type": "dimension", "$value": { "value": 0.375, "unit": "rem" } },
      "lg": { "$type": "dimension", "$value": { "value": 0.5, "unit": "rem" } }
    }
  },
  "semantic": {
    "color": {
      "surface": { "$type": "color", "$value": "{primitive.color.white}" },
      "text": { "$type": "color", "$value": "{primitive.color.gray.900}" },
      "border": { "$type": "color", "$value": "{primitive.color.gray.200}" },
      "focus": { "$type": "color", "$value": "{primitive.color.blue.600}" }
    }
  },
  "component": {
    "button": {
      "primary": {
        "background": { "$type": "color", "$value": "{primitive.color.blue.600}" },
        "backgroundHover": { "$type": "color", "$value": "{primitive.color.blue.700}" },
        "text": { "$type": "color", "$value": "{primitive.color.white}" }
      },
      "danger": {
        "background": { "$type": "color", "$value": "{primitive.color.red.600}" },
        "backgroundHover": { "$type": "color", "$value": "{primitive.color.red.700}" },
        "text": { "$type": "color", "$value": "{primitive.color.white}" }
      }
    }
  }
}

O script seguinte gera CSS Custom Properties e um mapa de tokens tipado para TypeScript a partir desse arquivo:

import { mkdirSync, readFileSync, writeFileSync } from "node:fs";
import { dirname } from "node:path";

const source = JSON.parse(readFileSync("tokens.json", "utf8"));

function getToken(path) {
  const node = path.split(".").reduce((current, key) => current?.[key], source);
  if (!node || typeof node.$value === "undefined") {
    throw new Error(`Unknown token reference: ${path}`);
  }
  return node.$value;
}

function resolveValue(value, stack = []) {
  if (typeof value === "string" && value.startsWith("{") && value.endsWith("}")) {
    const path = value.slice(1, -1);
    if (stack.includes(path)) {
      throw new Error(`Circular token reference: ${[...stack, path].join(" -> ")}`);
    }
    return resolveValue(getToken(path), [...stack, path]);
  }
  return value;
}

function toCssValue(value) {
  if (value && typeof value === "object") {
    if (typeof value.hex === "string") return value.hex;
    if (typeof value.value === "number" && typeof value.unit === "string") {
      return `${value.value}${value.unit}`;
    }
    throw new Error(`Unsupported token value: ${JSON.stringify(value)}`);
  }
  return String(value);
}

function walk(node, pathParts = [], result = {}) {
  if (!node || typeof node !== "object") return result;

  if (node && typeof node === "object" && typeof node.$value !== "undefined") {
    result[pathParts.join("-")] = toCssValue(resolveValue(node.$value));
    return result;
  }

  for (const [key, value] of Object.entries(node)) {
    if (key.startsWith("$")) continue;
    walk(value, [...pathParts, key], result);
  }

  return result;
}

const flat = walk(source);
const css = [
  ":root {",
  ...Object.entries(flat).map(([name, value]) => `  --${name}: ${value};`),
  "}",
  ""
].join("\n");

mkdirSync(dirname("src/styles/tokens.css"), { recursive: true });
mkdirSync(dirname("src/tokens.ts"), { recursive: true });
writeFileSync("src/styles/tokens.css", css);
writeFileSync("src/tokens.ts", `export const tokens = ${JSON.stringify(flat, null, 2)} as const;\n`);

console.log(`Generated ${Object.keys(flat).length} tokens.`);

Peça primeiro um levantamento, não uma reescrita completa da interface. Um bom pedido inicial é: “Encontre cores e espaços brutos repetidos, associe-os a possíveis tokens e entregue um relatório antes de editar.” A equipe consegue então validar nomes e significados sem comprometer dezenas de arquivos.

Criar componentes React tipados

A camada de componentes deve ser previsível. O Button abaixo reúne variantes, tamanhos, carregamento, estado desabilitado e foco visível. A API pública permanece pequena, enquanto as classes recorrentes ficam centralizadas.

import { forwardRef, type ButtonHTMLAttributes } from "react";
import { cva, type VariantProps } from "class-variance-authority";
import { clsx, type ClassValue } from "clsx";
import { twMerge } from "tailwind-merge";

function cn(...inputs: ClassValue[]) {
  return twMerge(clsx(inputs));
}

const buttonVariants = cva(
  [
    "inline-flex items-center justify-center gap-2 rounded-md font-medium",
    "transition-colors focus-visible:outline-none focus-visible:ring-2",
    "focus-visible:ring-[var(--semantic-color-focus)] focus-visible:ring-offset-2",
    "disabled:pointer-events-none disabled:opacity-50"
  ],
  {
    variants: {
      variant: {
        primary: [
          "bg-[var(--component-button-primary-background)]",
          "text-[var(--component-button-primary-text)]",
          "hover:bg-[var(--component-button-primary-backgroundHover)]"
        ],
        secondary: "border border-[var(--semantic-color-border)] bg-[var(--semantic-color-surface)] text-[var(--semantic-color-text)] hover:bg-gray-50",
        danger: [
          "bg-[var(--component-button-danger-background)]",
          "text-[var(--component-button-danger-text)]",
          "hover:bg-[var(--component-button-danger-backgroundHover)]"
        ]
      },
      size: {
        sm: "h-8 px-3 text-sm",
        md: "h-10 px-4 text-sm",
        lg: "h-12 px-6 text-base"
      }
    },
    defaultVariants: {
      variant: "primary",
      size: "md"
    }
  }
);

export interface ButtonProps
  extends ButtonHTMLAttributes<HTMLButtonElement>,
    VariantProps<typeof buttonVariants> {
  loading?: boolean;
}

export const Button = forwardRef<HTMLButtonElement, ButtonProps>(function Button(
  { className, variant, size, loading = false, disabled, children, ...props },
  ref
) {
  return (
    <button
      ref={ref}
      className={cn(buttonVariants({ variant, size }), className)}
      disabled={disabled || loading}
      aria-busy={loading || undefined}
      {...props}
    >
      {loading ? (
        <span
          aria-hidden="true"
          className="h-4 w-4 animate-spin rounded-full border-2 border-current border-r-transparent"
        />
      ) : null}
      <span>{children}</span>
    </button>
  );
});

A pergunta de revisão não é “o botão ficou bonito?”. A pergunta correta é “essa API é estável o bastante para vários times de produto usarem?”. Uma pessoa precisa avaliar nomes, comportamento padrão e compatibilidade antes de liberar a migração.

Usar Storybook como especificação executável

Todo estado relevante deve existir como story. Sem uma story, o estado fica difícil de discutir, comparar visualmente e testar de forma automática.

import type { Meta, StoryObj } from "@storybook/react-vite";
import { Button } from "./Button";

const meta = {
  title: "Design System/Button",
  component: Button,
  parameters: {
    layout: "centered",
    a11y: {
      test: "error"
    }
  },
  argTypes: {
    variant: {
      control: "select",
      options: ["primary", "secondary", "danger"]
    },
    size: {
      control: "select",
      options: ["sm", "md", "lg"]
    },
    loading: { control: "boolean" },
    disabled: { control: "boolean" }
  }
} satisfies Meta<typeof Button>;

export default meta;
type Story = StoryObj<typeof meta>;

export const Primary: Story = {
  args: {
    children: "Save changes",
    variant: "primary"
  }
};

export const Danger: Story = {
  args: {
    children: "Delete",
    variant: "danger"
  }
};

export const Loading: Story = {
  args: {
    children: "Saving",
    loading: true
  }
};

export const AllStates: Story = {
  render: () => (
    <div className="flex flex-wrap items-center gap-3">
      <Button variant="primary" size="sm">Small</Button>
      <Button variant="primary" size="md">Medium</Button>
      <Button variant="primary" size="lg">Large</Button>
      <Button variant="secondary">Secondary</Button>
      <Button variant="danger">Danger</Button>
      <Button disabled>Disabled</Button>
      <Button loading>Loading</Button>
    </div>
  )
};

Oriente Claude Code a preservar as stories existentes, adicionar somente os estados ausentes e explicar qualquer alteração de ID. Assim, snapshots visuais e relatórios de a11y continuam associados ao mesmo cenário.

Executar testes de componente, a11y e visual na CI

Verificações automáticas de acessibilidade não substituem teclado e leitor de tela, mas encontram cedo muitos problemas estruturais. Para Storybook baseado em Vite, @storybook/addon-vitest é o caminho recomendado atualmente. Ele transforma stories em testes no navegador; quando parameters.a11y.test = "error", uma violação reportada pelo addon de acessibilidade faz o teste de componente falhar.

Execute npm run test:storybook -- --run na CI. Diferentemente do fluxo antigo com test-runner, o Vitest addon não exige um servidor Storybook separado para os testes de componente e a11y. No exemplo abaixo, o Storybook compilado é servido apenas para o screenshot personalizado do Playwright.

Comece com poucos screenshots que representem estados de alto valor. Datas, animações, fontes externas e IDs aleatórios podem gerar ruído sem revelar uma regressão real.

Antes de ativar a CI, execute uma vez npx playwright test tests/button.visual.spec.ts --update-snapshots no aplicativo de destino, revise a imagem de referência e faça commit dela. Sem essa referência, a primeira execução falha porque o Playwright não tem o que comparar.

import { expect, test } from "@playwright/test";

test("button all states visual snapshot", async ({ page }) => {
  await page.goto("http://127.0.0.1:6006/iframe.html?id=design-system-button--all-states");
  await expect(page).toHaveScreenshot("button-all-states.png", {
    fullPage: true,
    animations: "disabled"
  });
});

Em seguida, conecte o mesmo fluxo ao GitHub Actions:

name: design-system-quality

on:
  pull_request:
    paths:
      - "tokens.json"
      - "scripts/build-tokens.mjs"
      - "src/components/**"
      - "src/styles/**"
      - ".storybook/**"
      - "tests/**"
      - "package.json"
      - "package-lock.json"

jobs:
  check:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run tokens:build
      - run: npx playwright install --with-deps chromium
      - run: npm run test:storybook -- --run
      - run: npm run build-storybook
      - run: >
          npx concurrently -k -s first -n server,tests
          "npx http-server storybook-static -p 6006"
          "npx wait-on http://127.0.0.1:6006 && npm run test:visual"

Quando a CI falhar, forneça ao Claude Code o ID da story, a violação específica do axe, os arquivos alterados e o diff visual. Evite copiar logs completos sem revisão, pois eles podem conter segredos, caminhos privados ou dados de clientes.

Definir um limite realista para a integração com Figma

Figma Variables são uma ótima entrada para Design Tokens, mas uma sincronização automática nos dois sentidos costuma ser arriscada no começo. Experimentos ainda não aprovados, nomes antigos de componentes e notas privadas podem chegar aos tokens de produção.

Área	Boa automação	Evite
Figma Variables	Exportar e comparar com tokens.json	Sobrescrever tokens de produção sem revisão
Componentes do Figma	Levantar candidatos a estado e prop	Decidir APIs React automaticamente
Comentários do Figma	Resumir dúvidas ainda abertas	Inferir a intenção final do design
Links do Storybook	Anexar URLs de stories à revisão de design	Tratar Storybook como aprovação de design

Peça primeiro um relatório de comparação e proíba alterações no arquivo de tokens:

Leia figma-tokens-export.json e tokens.json.
Crie um relatório em Markdown com:
1. tokens que existem no Figma, mas não no código
2. tokens que existem no código, mas não no Figma
3. diferenças de valor entre tokens semânticos correspondentes
Não edite tokens.json. Não renomeie tokens. Marque diferenças arriscadas em cores de foco, perigo e texto.

O objetivo não é sincronizar por sincronizar. O objetivo é produzir um diff pequeno e revisável para que design e engenharia decidam juntos.

Use case 1: unificar estados em um painel SaaS

Painéis SaaS concentram botões, formulários, tabelas e modais com muitos estados. Primeiro, Claude Code pode inventariar todos os usos atuais de Button. Depois, a equipe define props de compatibilidade e migra somente uma tela.

A pessoa responsável decide quais estados têm significado diferente no produto. Claude Code implementa o componente, as stories e os testes. A próxima tela só entra depois que o diff visual e o fluxo por teclado da primeira forem aprovados, mantendo o rollback pequeno.

Use case 2: alternar marcas em um produto white-label

Em um produto white-label, as cores primitivas mudam por cliente, mas tokens semânticos como surface, text e danger permanecem estáveis. Claude Code pode gerar CSS Custom Properties por marca e seletores de tema no Storybook a partir de arquivos já revisados.

O significado das cores não deve ser decidido automaticamente. Uma pessoa valida contraste, identidade visual e requisitos legais. A CI confirma que todas as marcas compilam os mesmos componentes e estados.

Use case 3: limpar CSS legado gradualmente

Um CSS antigo pode conter dez tons de azul quase iguais e pequenas variações de espaçamento. Claude Code consegue contar os valores brutos, agrupá-los por uso e entregar uma tabela de migração com candidatos a token. A primeira entrega deve ser um relatório, nunca uma substituição em massa.

Depois da aprovação, migre um componente por vez. Snapshots visuais revelam quando dois valores parecidos tinham finalidades diferentes. Essa etapa impede que uma limpeza técnica altere o design do produto sem intenção.

Use case 4: manter funis de marketing e contato mensuráveis

Botões de CTA, cartões de preço e estados de formulário precisam ser consistentes nas páginas de conversão. Um design system facilita testes A/B porque cada variante muda em um ponto controlado. Claude Code pode adicionar stories e screenshots e conferir estados de carregamento, erro e sucesso.

A escolha comercial da variante continua sendo humana e depende de dados reais. O design system apenas garante que o experimento seja implementado de forma comparável e acessível.

Armadilhas: causa e correção

Usar tokens primitivos diretamente nos componentes

Causa: o desenvolvedor escolhe blue-600 porque o valor já existe. Efeito: trocar a marca exige busca e substituição em muitos componentes. Correção: componentes consomem tokens semânticos ou específicos do componente; valores primitivos ficam na camada inferior.

Executar Storybook apenas na máquina local

Causa: stories são tratadas como documentação e não como entrada de teste. Efeito: o catálogo pode quebrar sem aviso. Correção: execute testes de stories com @storybook/addon-vitest e vitest --project=storybook em todo pull request relevante.

Criar snapshots de tudo logo no início

Causa: a equipe tenta alcançar cobertura total imediatamente. Efeito: animações, datas, fontes externas e IDs aleatórios geram diffs ruidosos. Correção: congele conteúdo dinâmico e comece pelas stories de maior impacto no negócio.

Considerar um resultado verde do axe como aprovação completa

Causa: um teste automático aprovado parece definitivo. Efeito: contexto, qualidade do texto, ordem de foco e compreensão no leitor de tela não são avaliados. Correção: combine automação com testes humanos de teclado e leitor de tela.

Pedir ao Claude Code uma migração gigante

Causa: um prompt amplo parece economizar tempo. Efeito: mudanças de API, diferenças visuais e regressões aparecem misturadas em um diff difícil de revisar. Correção: limite cada tarefa a um componente, fixe as áreas de arquivo e exija testes antes da entrega.

Checklist antes do merge

• Os nomes dos tokens expressam significado, não apenas aparência.
• As props dos componentes são pequenas, tipadas e estáveis.
• Estados disabled, loading, error, focus e hover existem no Storybook.
• A operação somente por teclado foi verificada.
• ARIA foi adicionado apenas quando o HTML nativo não resolve.
• Uma pessoa revisou todas as mudanças de snapshot visual.
• Diferenças do Figma foram salvas como artefato de revisão.
• Claude Code editou somente as áreas de arquivo autorizadas.
• Prompts, logs, stories e screenshots não contêm segredos nem dados privados de clientes.

Inclua esse checklist nas instruções do projeto. Assim, Claude Code poderá reutilizá-lo como critério de aceite em sessões futuras.

Escolha o próximo passo

Confirme primeiro que tokens.json gera variáveis CSS e constantes TypeScript, que as stories de Button renderizam todos os estados e que a CI reproduz o build do Storybook, os testes de acessibilidade e os snapshots visuais. Mantenha a integração com Figma apenas no modo de relatório até que a equipe defina a fonte de verdade.

Se sua equipe precisa de apoio para implementar um design system, adotar Storybook, revisar acessibilidade ou estruturar um fluxo de refatoração de UI com Claude Code, consulte a página de treinamento e consultoria.

O que foi realmente testado

Em 22 de julho de 2026, o código de build-tokens.mjs deste artigo foi extraído e executado com o exemplo completo de tokens.json. O processo terminou com exit code 0, gerou 25 CSS Custom Properties e o mapa de tokens TypeScript e resolveu a referência {primitive.color.blue.600} para #2563eb. Um fixture negativo com uma referência desconhecida terminou com exit code diferente de zero e a mensagem Unknown token reference.

Os trechos JSON também foram interpretados, e as cercas de código e os links internos foram verificados. Os comandos do Storybook foram comparados com a documentação oficial atual do Vitest addon e de migração. O Storybook não está instalado neste repositório do site; portanto, os testes de componente e visuais devem ser executados no aplicativo de destino antes de adotar o fluxo.