Um agente de programação com IA só consegue seguir uma referência visual na medida em que ela define suas decisões. Se o projeto é seu e você já tem regras de marca aprovadas, pode reuni-las em um arquivo DESIGN.md que possa ser revisado e depois usar o Claude Code em duas pequenas edições que você mesmo inspeciona. A entrega é a sua especificação aprovada. As duas edições verificam se ela foi útil naqueles materiais específicos; não estabelecem como será uma edição futura.

Este procedimento se baseia em documentação. O BIG CHANGE analisou uma coleção de arquivos de design fixada em uma revisão e os manuais do Claude Code da Anthropic em 20 de outubro de 2026. Não executamos o Claude Code, não editamos nem renderizamos os dois materiais e não medimos custo ou qualidade de design.

A principal mudança

  • O que mudou: O proprietário pode criar uma especificação visual versionada com decisões aprovadas e fornecer esse arquivo exato ao Claude Code antes de uma edição delimitada.
  • Por que importa: Uma única fonte conferida permite comparar as regras de cor, tipografia e layout com duas revisões reais, enquanto o proprietário decide se cada resultado é aceitável.
  • O que observar: O arquivo precisa ser lido por completo antes de cada edição. Estar presente no projeto, citar um caminho ou receber uma garantia do Claude não comprova que ele foi carregado ou seguido.

Antes de começar

Você precisa de um projeto próprio, permissão para editá-lo, dois pequenos materiais existentes que possa renderizar e uma cópia de trabalho ou ponto de controle de versão recuperável. Podem ser duas páginas ou uma página e uma apresentação, desde que você conheça o fluxo real de edição e renderização de cada projeto. Escolha uma alteração visual limitada para cada material. Preserve os textos atuais, links e interações funcionais para comparação.

Reúna os valores de cor aprovados pelo proprietário e suas funções, fontes licenciadas ou permitidas e alternativas, regras de uso de logotipos e imagens, público-alvo, dimensões e requisitos de acessibilidade. Use o registro real de aprovação ou peça ao proprietário que resolva as escolhas pendentes. O site público de uma empresa ou a análise de design de outra pessoa não autoriza valores ou recursos para o seu projeto. Aprovar um recurso também não autoriza automaticamente seu envio a um provedor de modelos.

Configure o Claude Code com uma conta ou provedor elegível e revise os termos de uso de dados e as permissões de ferramentas da conta antes de expor código, textos ou recursos privados. Um projeto armazenado localmente ainda pode enviar conteúdo a um serviço de modelos. Confira quem pode ver o material, quais ferramentas podem ler ou alterar arquivos e se você pode enviar cada item. As orientações de custo dependem da conta e do provedor; este guia não pode atribuir um preço fixo à sua sessão.

A coleção Awesome DESIGN.md fixada em uma revisão é uma inspiração opcional para as seções do arquivo. Ela analisa sites públicos; não é um manual de marca aprovado pelo proprietário. Você pode escrever o arquivo diretamente com as decisões aprovadas. Se copiar texto do repositório, preserve o aviso de direitos autorais e permissão MIT. Esse aviso não concede direitos sobre marcas, arquivos de fontes ou imagens de outro site.

Crie a referência aprovada pelo proprietário

  1. Crie brand-reference/DESIGN.md no projeto próprio. Preencha este esquema mínimo com o registro de aprovação. O texto entre colchetes indica informações que o proprietário deve fornecer; não sugere uma marca. Mantenha um item marcado como UNRESOLVED até o proprietário decidir. Não peça ao Claude que invente um valor para preencher uma lacuna.
Markdown
# Visual specification

Owner: [owner or approving role]
Approved version/date: [version and approval date, or UNRESOLVED]
Audience and artifact purpose: [owner-approved description]
Approval evidence: [internal record or location, without private data in a shared copy]

## Color roles and values
- Background: [approved value and color format, or UNRESOLVED]
- Text: [approved value and color format, or UNRESOLVED]
- Primary action: [approved value and color format, or UNRESOLVED]
- Link, border and status roles: [each approved value, or UNRESOLVED]

## Typography and scale
- Heading family and permitted fallback: [approved names, or UNRESOLVED]
- Body family and permitted fallback: [approved names, or UNRESOLVED]
- Heading/body sizes, weights and line heights: [approved scale, or UNRESOLVED]
- Font license or use restriction: [approved terms, or UNRESOLVED]

## Spacing and layout
- Spacing scale, content width and grid: [approved values, or UNRESOLVED]
- Target artifact dimensions: [approved sizes, or UNRESOLVED]

## Components and states
- Buttons, links, inputs and navigation: [approved appearance and behavior]
- Hover, focus, disabled and error states: [approved rules, or UNRESOLVED]

## Responsive and accessibility rules
- Desktop/phone behavior and breakpoints: [approved rules, or UNRESOLVED]
- Contrast, readable type, focus order and touch use: [approved requirements]

## Assets and forbidden substitutions
- Permitted logo/image assets and usage: [approved paths and permissions]
- Do not substitute: [owner-approved prohibited colors, fonts, marks or patterns]

## Owner approval and changes
- Approved by: [person or role and date, or UNRESOLVED]
- Version: [version]
- Changelog: [date, change, approver]
- Unresolved decisions: [list, or "none" after owner review]
  1. Confira cada linha preenchida com as decisões originais do proprietário, incluindo os direitos de uso de fontes e imagens. Resolva com ele conflitos entre estilos antigos do projeto e as regras atualmente aprovadas. Peça a aprovação desse arquivo exato e registre sua versão. Suspenda qualquer edição que dependa de um valor não resolvido. Salve o arquivo aprovado e os dois materiais iniciais no controle de versão ou em outra cópia recuperável.

Use o arquivo em duas edições delimitadas

  1. No projeto próprio, inicie uma sessão do Claude Code com a conta e as permissões conferidas. Forneça os caminhos exatos de brand-reference/DESIGN.md e do primeiro material. Peça primeiro ao Claude que leia toda a referência e o material, depois pare antes de editar. Inspecione o resultado real de leitura de arquivo ou da ferramenta para conferir o caminho e o conteúdo completo. Leitura negada, resultado truncado, mera menção ao caminho ou resumo verbal não bastam. A Anthropic documenta os arquivos de instruções do projeto como uma opção de configuração separada; não presuma que um DESIGN.md qualquer seja descoberto automaticamente nem dependa de uma referência @ funcionar da mesma forma em todas as versões.
  2. Quando a leitura completa estiver visível, peça a única alteração visual escolhida para o primeiro material, usando apenas as regras aprovadas. Limite os arquivos alterados; preserve textos, links, controles e código não relacionado. Peça para ver as diferenças propostas e a forma estabelecida de renderizar o material no projeto. Inspecione cada arquivo alterado antes de aceitá-lo. Rejeite cores, fontes, recursos, dependências ou edições extras sem aprovação.
  3. Renderize o primeiro material com o fluxo real do projeto. Compare o resultado com o arquivo aprovado e o material inicial em tamanhos de computador e celular adequados ao projeto. Confira valores dos tokens nos arquivos alterados, contraste legível, hierarquia de títulos e tipografia, cortes ou transbordamento horizontal, foco visível, teclado e interações afetadas, além da preservação dos textos e links. Registre a versão da referência, a revisão do material, verificações e correções. Uma descrição de uma renderização não é o resultado renderizado.
  4. Para o segundo material, informe novamente o caminho exato e brand-reference/DESIGN.md. Solicite uma nova leitura completa antes da edição e inspecione o resultado da ferramenta. Depois peça uma alteração delimitada, revise as diferenças, renderize com o fluxo próprio do segundo material e repita as mesmas verificações. Compare as duas revisões com a mesma versão do arquivo aprovado. Registre cada regra como seguida, descumprida ou dependente de uma revisão aprovada pelo proprietário; corrija os desvios e confira novamente os dois materiais se a referência mudar.

O trabalho termina com a especificação aprovada e versionada, duas revisões inspecionadas e renderizadas e um registro breve do que cumpriu ou não as regras. Preserve as revisões originais para poder reverter. Se uma leitura falhar, confira o caminho exato, as permissões e o tamanho do arquivo ou possível truncamento antes de pedir uma edição. Se a especificação conflitar com estilos do projeto ou acessibilidade, obtenha a decisão do proprietário e reduza a alteração. Se um material não puder ser renderizado ou uma interação não puder ser verificada, deixe a edição sem aceitar até a verificação ser possível. Mudanças futuras de marca exigem uma nova revisão deliberada dos resultados anteriores.

Para outra tarefa que usa um arquivo da comunidade como referência de uma página, veja nosso guia de DESIGN.md fixado em uma revisão. O trabalho deste guia é primeiro criar e aprovar a sua própria especificação.

Fontes e leituras adicionais

  • O README do Awesome DESIGN.md fixado em uma revisão fornece seções de exemplo e descreve seus arquivos como análises de sites públicos fornecidas no estado em que se encontram. Seu discurso sobre qualidade do resultado não é um resultado testado aqui. A licença MIT rege material copiado do repositório, não a identidade ou os recursos de terceiros.
  • O guia de início da Anthropic cobre a configuração de conta e projeto. Seus fluxos comuns e seu manual de memória do projeto descrevem fluxos de arquivos e instruções; nenhum comprova que esse arquivo independente foi lido por completo na sessão do leitor.
  • Os manuais da Anthropic sobre permissões, uso de dados e custos explicam controles e termos específicos da conta. Não estabelecem uma edição observada, processamento apenas local, conta fixa ou ganho de qualidade para este guia.