Por que o Cline + DESIGN.md é uma combinação forte

O Cline tem três características que o tornam ideal para design systems:

Autonomia — ele não espera aprovação para cada linha. Se as regras estão claras, ele segue e produz. DESIGN.md dá as regras visuais que faltam.
Persistência — .clinerules são lidas em toda tarefa, não só quando você lembra de mencionar. O design system fica “always on”.
Memory Bank — decisões de design tomadas numa sessão carregam para a próxima. “Decidimos usar cards com sombra suave e sem borda” não precisa ser repetido.

Sem DESIGN.md, o Cline é um desenvolvedor talentoso mas sem briefing visual. Com DESIGN.md, ele vira um dev que já leu o design system inteiro antes de tocar no código.

Passo a Passo de Configuração

1. Instalar o Cline no VS Code

Se ainda não tem: Extensions → buscar “Cline” → Install. Configure a API key do modelo que preferir (Claude, GPT, etc.).

2. Colocar o DESIGN.md na raiz

meu-projeto/
├── DESIGN.md
├── .clinerules
├── .cline/
│   └── memory-bank/
├── src/
└── ...

3. Criar o arquivo .clinerules

O .clinerules é o arquivo mais poderoso do ecossistema Cline. Ele é lido automaticamente no início de TODA tarefa — sem exceção. Crie na raiz do projeto:

# .clinerules

## Design System

Este projeto segue um design system documentado em DESIGN.md na raiz.

### Regra absoluta

Antes de gerar, modificar ou sugerir qualquer componente de UI:
1. Leia o arquivo DESIGN.md completo
2. Extraia os tokens relevantes (cores, tipografia, espaçamento)
3. Aplique-os no código gerado
4. Verifique as restrições listadas no DESIGN.md antes de finalizar

### Padrões obrigatórios

- Cores: usar APENAS os tokens definidos. Nunca inventar cores.
- Tipografia: respeitar a escala exata. Sem tamanhos intermediários.
- Espaçamento: múltiplos do valor base definido no DESIGN.md.
- Componentes: seguir os padrões documentados (botões, cards, inputs, etc.)
- Estados: todo elemento interativo deve ter hover, focus e disabled.
- Restrições: a seção "Restrições" do DESIGN.md é lei. Não violar.

### Quando o DESIGN.md não cobre um caso

Se precisar de um token ou padrão não documentado:
1. Inferir a partir dos padrões existentes (consistência > criatividade)
2. Documentar a decisão no memory bank para referência futura
3. Avisar o usuário sobre a decisão tomada

### Framework CSS

[Adapte esta seção ao seu projeto]
- Se usa Tailwind: mapear tokens para classes customizadas
- Se usa CSS Modules: criar variáveis CSS a partir dos tokens
- Se usa styled-components: criar theme object a partir dos tokens

4. Configurar a Memory Bank

A Memory Bank do Cline persiste informações entre sessões. Crie o diretório:

mkdir -p .cline/memory-bank

Crie um arquivo inicial de contexto de design:

# .cline/memory-bank/design-decisions.md

## Decisões de design tomadas neste projeto

### Data: [preenchido automaticamente pelo Cline]

- Design system source of truth: DESIGN.md na raiz
- Framework CSS: [Tailwind/CSS Modules/styled-components]
- Convenção de nomes: [BEM/utility-first/component-scoped]
- Ícones: [Lucide/Heroicons/custom SVG]

## Padrões emergentes

[O Cline atualiza isso conforme toma decisões]

5. Criar regras por pasta (opcional mas recomendado)

O Cline suporta .clinerules em subdiretórios. Quando ele trabalha em arquivos dentro daquela pasta, lê as regras locais além das globais:

# src/components/.clinerules

## Regras para componentes

- Todo componente deve ser exportado como named export
- Props devem ter interface TypeScript explícita
- Componentes visuais devem seguir DESIGN.md da raiz
- Componentes devem aceitar className para override
- Documentar variantes com JSDoc acima do componente

Exemplo Concreto de Uso

Abra o Cline e digite:

Crie uma página de dashboard com:
- Header com logo e navegação
- Sidebar com menu de links
- Área principal com grid de stats cards
- Cada stat card mostra: ícone, label, valor numérico, variação percentual
- Design responsivo: sidebar colapsa em mobile

O Cline lê o .clinerules, depois abre o DESIGN.md, extrai os tokens e gera:

// src/pages/Dashboard.tsx
import { StatsCard } from '@/components/StatsCard';
import { Sidebar } from '@/components/Sidebar';
import { Header } from '@/components/Header';

export function Dashboard() {
  return (
    <div className="min-h-screen bg-[#F8F9FA]">
      <Header />
      <div className="flex">
        <Sidebar />
        <main className="flex-1 p-8">
          <h1 className="text-[32px] font-bold text-[#202124] leading-[1.2]">
            Dashboard
          </h1>
          <div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-4 gap-6 mt-8">
            <StatsCard
              icon="users"
              label="Usuários ativos"
              value="12,847"
              change={+12.5}
            />
            <StatsCard
              icon="revenue"
              label="Receita mensal"
              value="R$ 84.320"
              change={+8.2}
            />
            <StatsCard
              icon="conversion"
              label="Taxa de conversão"
              value="3.24%"
              change={-0.8}
            />
            <StatsCard
              icon="sessions"
              label="Sessões"
              value="48.291"
              change={+15.3}
            />
          </div>
        </main>
      </div>
    </div>
  );
}

// src/components/StatsCard.tsx
interface StatsCardProps {
  icon: string;
  label: string;
  value: string;
  change: number;
}

export function StatsCard({ icon, label, value, change }: StatsCardProps) {
  const isPositive = change > 0;

  return (
    <div className="bg-white rounded-2xl p-6 shadow-sm hover:shadow-md transition-shadow">
      <div className="flex items-center gap-3">
        <div className="w-10 h-10 rounded-lg bg-[#F8F9FA] flex items-center justify-center">
          <Icon name={icon} className="w-5 h-5 text-[#1A73E8]" strokeWidth={1.5} />
        </div>
        <span className="text-sm text-[#5F6368]">{label}</span>
      </div>
      <p className="text-[32px] font-bold text-[#202124] mt-4 leading-[1.2]">
        {value}
      </p>
      <span className={`text-sm font-medium ${
        isPositive ? 'text-[#34A853]' : 'text-[#D93025]'
      }`}>
        {isPositive ? '↑' : '↓'} {Math.abs(change)}%
      </span>
    </div>
  );
}

O Cline gerou o card usando: bg-white (surface), rounded-2xl (large: 16), padding 24px (múltiplo de 8), cores #1A73E8 (primary), #34A853 (secondary/success), #D93025 (error), tipografia 32px para valores (da escala). Tudo extraído do DESIGN.md.

Dicas Específicas do Cline

Use Custom Instructions junto com .clinerules

No painel de Settings do Cline, há um campo “Custom Instructions”. Use-o para regras que valem para TODOS os projetos:

Ao trabalhar em projetos com DESIGN.md na raiz, sempre leia esse arquivo antes de gerar UI.
Priorize consistência visual. Pergunte quando houver ambiguidade no design.

O .clinerules é por projeto. Custom Instructions é global. Use os dois.

Aproveite o modo de aprovação

O Cline pede aprovação antes de criar/editar arquivos. Use esse momento para verificar se ele seguiu o DESIGN.md. Se gerou cores erradas, rejeite e instrua:

Rejeitado. A cor do botão deve ser #1A73E8 (primary do DESIGN.md), não #3B82F6.

Ele aprende no contexto da sessão e não repete o erro.

Memory Bank como histórico de design

Configure o Cline para logar decisões de design na Memory Bank. No .clinerules:

### Logging de decisões

Após criar um componente novo ou tomar uma decisão visual não coberta pelo DESIGN.md:
1. Adicione a decisão em .cline/memory-bank/design-decisions.md
2. Formato: data, componente, decisão, justificativa

Isso cria um registro vivo de como o design system evolui.

Force a leitura explícita

Se em algum prompt o Cline parecer ignorar o design system, seja explícito:

Leia o DESIGN.md antes de continuar. Corrija os componentes para usar os tokens corretos.

O Cline pode reler arquivos a qualquer momento. Não hesite em pedir.

.clinerules como documentação viva

O arquivo .clinerules é markdown puro. Times podem revisá-lo em PRs, versioná-lo, discutir mudanças. É documentação executável: escrito para humanos lerem, mas executado pelo agente.

Troubleshooting e Gotchas

O Cline não lê o .clinerules

Verifique:

O arquivo está na raiz do projeto (mesmo nível do package.json)
O nome é exatamente .clinerules (com ponto, sem extensão)
O VS Code tem o projeto aberto como workspace (File > Open Folder)

Memory Bank não persiste entre sessões

A Memory Bank depende da versão do Cline. Verifique:

Extensão atualizada para a versão mais recente
Diretório .cline/memory-bank/ existe e tem permissão de escrita
O arquivo não está no .gitignore (se quiser compartilhar com o time)

Cline gera UI inconsistente entre componentes

Provável causa: o DESIGN.md é muito longo e o contexto é cortado. Soluções:

Mantenha o DESIGN.md abaixo de 3000 tokens (ideal: 1500-2500)
Use seções com headers claros — o Cline navega melhor
Coloque as regras mais críticas no TOPO do arquivo
Tokens no YAML front matter são mais concisos que prosa

Conflito entre .clinerules global e por pasta

Regras de subdiretório NÃO sobrescrevem as da raiz — elas se somam. Se houver contradição, a regra da raiz prevalece. Mantenha hierarquia clara:

Raiz: regras universais (design system, convenções)
Subdiretório: regras de escopo (padrões de componentes, padrões de páginas)

O Cline tenta editar o DESIGN.md

Às vezes o Cline interpreta “seguir o design system” como “editar o design system”. Adicione ao .clinerules:

## Arquivos read-only

Os seguintes arquivos são somente leitura. Nunca modificar:
- DESIGN.md
- .clinerules (raiz)

Workflow Recomendado

Início do projeto: crie DESIGN.md + .clinerules antes de qualquer código
Durante desenvolvimento: use o Cline para gerar componentes com referência ao design system
Revisão: verifique se a Memory Bank registrou decisões emergentes
Iteração: atualize o DESIGN.md conforme o design evolui
Time: commite .clinerules e DESIGN.md — todos do time se beneficiam

Conclusão e Próximo Passo

O Cline com DESIGN.md é para quem quer um agente que age, não que sugere. A combinação .clinerules (regras persistentes) + Memory Bank (memória entre sessões) + DESIGN.md (tokens de design) cria um workflow onde o agente mantém consistência visual sem supervisão constante.

O setup leva 10 minutos. O retorno é imediato: primeiro componente já sai no padrão. E conforme o projeto cresce, a Memory Bank acumula contexto que torna o Cline cada vez mais preciso.

Próximos passos:

O que é DESIGN.md — especificação completa do formato
Biblioteca de DESIGN.md — 450+ design systems prontos
Guias de outros agentes: GitHub Copilot · Cursor · Aider · Continue.dev

DESIGN.md + Cline