Arquivos Markdown

1# Orientações para colaborar neste projeto2 3Este é um exemplo de CLAUDE.md para um projeto web. Ajuste estas instruções à estrutura e às decisões reais do seu repositório.4 5## Comece pelo contexto6 7Leia o README, o package.json e as instruções aplicáveis à pasta que será alterada. Se houver um DESIGN.md, use-o como referência visual. Confira o estado do Git antes de editar e preserve alterações que já estavam presentes.8 9## Entenda a tarefa10 11Identifique o resultado esperado e os arquivos envolvidos. Faça escolhas rotineiras com base nas convenções do projeto. Pergunte quando faltar uma decisão que afete o comportamento, os dados ou o escopo.12 13## Implementação14 15- Reutilize componentes e funções existentes antes de criar novas abstrações.16- Preserve rotas, contratos de API e formatos de dados que já estejam em uso.17- Separe conteúdo de apresentação quando isso facilitar a manutenção.18- Trate carregamento, vazio, erro e sucesso nos fluxos assíncronos.19- Use labels e nomes acessíveis nos controles.20- Garanta que funções importantes também possam ser usadas no celular.21 22## Dados e autenticação23 24Não coloque credenciais no código nem em exemplos públicos. Valide entradas no servidor e respeite a autorização de cada usuário. Não use uma chave administrativa no frontend. Migrações devem preservar dados existentes e ter um objetivo definido.25 26## Dependências27 28Antes de instalar uma biblioteca, confira se o projeto já resolve a necessidade. Explique por que a nova dependência é necessária e mantenha o arquivo de lock atualizado.29 30## Conferência31 32Consulte os scripts disponíveis no package.json. Não invente comandos de build, lint ou teste. Execute testes somente quando a pessoa tiver pedido ou autorizado. Informe quais verificações realmente foram executadas e seus limites.33 34## Entrega35 36Descreva o que mudou, onde mudou e como foi conferido. Avise quando uma alteração depender de configuração externa. Não afirme que um fluxo está funcionando de ponta a ponta se apenas a compilação ou uma leitura pública foi conferida.37 38Publicações, merges e mudanças em serviços externos seguem a autorização dada pela pessoa responsável pelo projeto.39 40## Exemplo de pedido41 42“Adicione a tela de configurações reutilizando o design e a autenticação existentes. Antes de editar, leia as instruções do repositório. Ao terminar, resuma os arquivos alterados e as verificações realizadas.”43 

1---2name: revisar-interface3description: Revise a clareza, a acessibilidade e o comportamento responsivo de uma interface existente, preservando sua identidade visual.4---5 6# Revisar uma interface antes de publicar7 8Exemplo de skill para projetos web. Adapte o fluxo ao seu ambiente e às ferramentas disponíveis.9 10## Quando usar11 12Use quando a pessoa pedir uma revisão de uma tela, de um formulário ou de um fluxo já implementado. O objetivo é encontrar problemas concretos e propor mudanças pequenas e justificadas.13 14## Contexto necessário15 16Antes da revisão, identifique:17 181. Qual tarefa a pessoa quer concluir.192. Quem usa a tela e em quais dispositivos.203. Qual arquivo ou rota representa a implementação atual.214. Quais decisões visuais precisam ser preservadas.22 23Se essas informações estiverem no projeto, leia-as antes de perguntar.24 25## Procedimento26 27### 1. Observe a tela real28 29Quando houver acesso à aplicação, observe uma largura de computador e uma de celular. Aguarde o conteúdo carregar. Se não houver acesso, diferencie observações de código de observações visuais.30 31### 2. Confira a hierarquia32 33Localize título, conteúdo principal e ação principal. Verifique se a pessoa consegue entender a tarefa sem ler toda a tela e se informações relacionadas aparecem juntas.34 35### 3. Confira interação e acessibilidade36 37- Campos têm labels visíveis?38- Controles recebem foco por teclado?39- Um botão com apenas ícone tem nome acessível?40- Erros apontam o campo e uma forma de recuperação?41- Existe feedback durante o envio?42- A função continua disponível sem hover?43- Conteúdo importante é cortado no celular?44 45### 4. Organize os achados46 47Para cada problema, registre o local, o comportamento observado, o impacto e uma correção proposta. Diferencie falhas que impedem uma tarefa de preferências estéticas.48 49### 5. Corrija dentro do escopo50 51Quando a implementação estiver autorizada, preserve componentes, dados e convenções existentes. Não transforme uma revisão pontual em um redesign geral. Execute testes somente quando isso tiver sido solicitado ou autorizado.52 53## Formato de entrega54 55```markdown56## Resumo57 58Tarefa revisada e evidência disponível.59 60## Problemas61 62- Local: componente ou trecho da tela.63- Observado: o que aconteceu.64- Impacto: por que isso atrapalha a tarefa.65- Correção: mudança concreta sugerida ou aplicada.66 67## Limites68 69O que não foi possível conferir e qual evidência ainda falta.70```71 72Não invente capturas, métricas, resultados de testes ou validações que não foram realizadas.73 

1# Interface clara para produtos de IA2 3Este é um exemplo de direção visual. Adapte os valores à identidade do seu produto antes de usar.4 5## Objetivo6 7Ajude a pessoa a descobrir conteúdo, entender o que ele faz e escolher uma ação. A interface deve deixar o resultado em evidência e manter a navegação previsível.8 9## Cores10 11Use tokens semânticos para evitar cores diferentes em cada tela:12 13```css14:root {15  --background: #fafafa;16  --surface: #ffffff;17  --foreground: #17181a;18  --muted: #565660;19  --border: #dedee5;20  --primary: #17181a;21  --primary-foreground: #ffffff;22}23```24 25Reserve cores de destaque para estados e conteúdo. Não dependa apenas de cor para comunicar erro, seleção ou sucesso.26 27## Tipografia e hierarquia28 29- Use uma família sem serifa na interface.30- Títulos devem ser curtos e explicar o conteúdo da seção.31- Texto de leitura deve ter aproximadamente 65 a 75 caracteres por linha.32- Use fonte monoespaçada somente em código, comandos e configurações.33- Nome, foto e emblemas pertencem ao mesmo grupo de autoria; o @ aparece em uma segunda linha.34 35## Espaçamento e componentes36 37- Trabalhe com uma escala de 4, 8, 12, 16, 24, 32 e 48 pixels.38- Elementos do mesmo grupo ficam próximos; seções diferentes recebem mais espaço.39- Cards usam cantos de 16 pixels, imagem acima e informações abaixo.40- Cada área tem uma ação principal. Ações secundárias não devem competir com ela.41- Formulários têm labels visíveis e instruções específicas junto ao campo.42 43## Responsividade44 45No celular, empilhe conteúdo em uma coluna. Não reduza o texto inteiro para caber. Garanta que menus, filtros e ações possam ser usados por toque, sem depender de hover.46 47## Estados obrigatórios48 49Para cada componente, considere carregamento, vazio, erro, sucesso, foco e ação em andamento. Um erro deve explicar como continuar; uma ação em andamento deve impedir envios repetidos.50 51## Acessibilidade52 53- Mantenha contraste de pelo menos 4,5:1 no texto comum.54- Preserve foco visível e ordem de navegação coerente.55- Dê nome acessível aos botões que mostram apenas ícone.56- Respeite a preferência por movimento reduzido.57- Permita ler e operar a página sem animação.58 59## Como pedir uma implementação60 61“Leia DESIGN.md, identifique os componentes que já existem e implemente a tela seguindo esta direção. Explique quais decisões você reaproveitou e quais estados foram considerados.”62