Communitygithub.com

bompus/hr-better-layout

Regras de layout para UI web: agrupamento, alinhamento, espaçamento, ordem de leitura, breakpoints responsivos, propriedades lógicas e corte em larguras estreitas. Use ao construir ou revisar CSS de layout de página ou componente.

O que é hr-better-layout?

Este skill define um conjunto de regras de layout para interfaces web, com foco em semântica visual antes mesmo da leitura do texto. Ele orienta sobre agrupamento por espaçamento, alinhamento consistente, ordem de importância, e uso de propriedades lógicas para suporte a diferentes direções de leitura. O skill também detalha breakpoints baseados no conteúdo, não em dispositivos, e enfatiza a testagem com redimensionamento, zoom e espelhamento RTL. Suporta qualquer projeto de interface que utilize CSS e sistemas de design, sendo útil para desenvolvedores que buscam consistência e acessibilidade no layout.

Funciona com✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/bompus/house-rules/tree/HEAD/skills/hr-better-layout

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Layout

Posição, espaçamento e alinhamento carregam hierarquia antes mesmo de uma palavra ser lida. Este skill constrói essa estrutura e a testa sob estresse: redimensione, traduza, espelhe para RTL.

Escreva cada correção no sistema de estilos do projeto. Os números abaixo são pontos de partida para interfaces sem um sistema de densidade estabelecido, e onde um se aplica, use-o como escrito em vez de um substituto familiar. Mantenha elementos deliberados da plataforma, ferramentas profissionais compactas e tokens do projeto onde ainda passarem nos testes de estresse.

Áreas de toque e comportamento de foco pertencem a hr-better-accessibility. Raio, sombras e animação estão fora deste skill. Comprimento de linha e espaçamento de texto pertencem a hr-better-typography.

Agrupe com espaço, não com linhas

Espaço agrupa primeiro, formas de fundo em segundo, linhas separadoras por último e apenas onde o espaço sozinho não consegue carregar a estrutura. O espaçamento entre grupos deve ser pelo menos 2× o espaçamento dentro de um (8px intra-grupo para 16px+ inter-grupo), ou o agrupamento soa como ruído. Bordas de alinhamento e ordenação por importância estão em grouping-and-alignment.md.

Mantenha controles distintos do conteúdo

Dê a cada elemento interativo uma forma de fundo, uma borda ou uma zona de posicionamento consistente. Um controle estilizado como o texto estático ao lado não é percebido como um controle.

Alinhe a bordas compartilhadas

Escolha bordas de alinhamento e mantenha-se nelas; cada borda desalinhada soa como ruído. Use um passo de espaçamento do projeto por nível de subordinação, onde 16px é um padrão útil.

Use propriedades lógicas para layout dependente de direção: padding-inline-start, margin-inline-end. Reserve left e right físicos apenas para geometria genuinamente física.

Ordene por importância

O conteúdo mais importante fica próximo ao topo e à borda inicial. A ordem de leitura flui de cima para baixo, da borda inicial para a final. Pense em termos de início e fim, não esquerda e direita.

Sugira conteúdo oculto

Divulgação progressiva precisa de um indicador visível. Use o sinal estabelecido pelo projeto, ou deixe o próximo item aparecer 16–32px além da borda de rolagem, ou mostre um controle de divulgação. Conteúdo oculto sem nenhum sinal pode muito bem não existir.

Espaço de respiro entre alvos

Sem um sistema de densidade estabelecido, comece com 12px entre controles adjacentes com borda ou preenchidos e 24px ao redor de controles sem borda, apenas com texto e ícone. Layouts compactos podem usar menos, desde que as áreas de toque do hr-better-accessibility não se sobreponham e os controles permaneçam distintos. Margens de layout e receitas de breakpoint estão em spacing-and-adaptivity.md.

Recue botões das bordas

Em layouts de conteúdo, mantenha botões de largura total dentro das margens do layout com um raio visível, começando perto de 16px inline no mobile. Ações de ponta a ponta funcionam quando seguem a estética estabelecida da plataforma, consideram áreas seguras e permanecem distinguíveis da UI do sistema.

Conteúdo sangra, controles flutuam

Fundos e mídia se estendem até as bordas da viewport. Controles e texto permanecem dentro das margens do layout e áreas seguras (env(safe-area-inset-*)). Elementos fixos da plataforma flutuam acima da camada de conteúdo, sem bloqueá-la.

Mantenha a estrutura até quebrar

Breakpoints vêm do conteúdo, não de presets de dispositivos. Mantenha o layout expandido enquanto couber genuinamente e colapse tarde. Prefira container queries para adaptação no nível do componente, e teste primeiro os tamanhos menor e maior.

Planeje crescimento e corte

Strings traduzidas crescem, e as curtas crescem proporcionalmente mais, então um rótulo de botão de uma palavra é o item mais arriscado na tela. Não coloque largura ou altura fixa em um contêiner de texto, e permita que linhas quebrem. Teste com pseudo-localização e uma localidade representativa, em vez de orçar uma porcentagem.

Nunca estacione uma ação crítica onde redimensionar ou rolar a corte. Mantenha-a no fluxo normal, ou em um elemento fixo estável adequado ao produto.

Antes de finalizar

ErroCorreção
margin-left / padding-right em um layout localizávelmargin-inline-start / padding-inline-end
Botão de layout de conteúdo toca a borda da viewportRecue dentro das margens do projeto; mantenha elementos deliberados da plataforma
Breakpoints em 768/1024 porque são os padrõesQuebre onde o conteúdo realmente para de caber
Contêiner de texto com largura fixa dimensionado para um idiomamax-width e quebra de linha; teste com pseudo-localização
Ação primária na parte inferior sujeita a corte de um painelPosicionamento fixo ou elemento fixo estável com padding de área segura
100vh em shell de aplicativo ou hero no mobile100dvh para um shell que acompanha o chrome do navegador, 100svh para primeira tela
Texto longo empurra a ação final de uma linha para fora da tela ou achata seu avatarmin-width: 0 na coluna de texto, flex-shrink: 0 em itens de tamanho fixo

Relatórios

Severidade. HIGH bloqueia conteúdo ou uma ação em uma viewport suportada. MEDIUM prejudica hierarquia, ordem de leitura ou adaptabilidade. LOW é polimento de alinhamento ou espaçamento isolado.

Verificação. Sem navegador: propriedades lógicas no lugar de físicas, container e media queries contra a lista de viewports suportadas e ordem do DOM contra a ordem de leitura pretendida. Com um navegador: cada largura suportada, zoom de 200% e espelhamento RTL. Relate cada verificação que não pôde executar como Não verificado.

Formato. Agrupe descobertas sob o princípio que cada uma viola, ordenadas por severidade, uma linha por causa raiz listando cada local onde aparece:

SeveridadeLocalizaçãoAntesDepoisPor quê

Localização é caminho/para/arquivo:linha. Por quê nomeia o princípio e o impacto no usuário.

Relate Bloquear quando qualquer HIGH permanecer, Aprovar caso contrário, deixando o restante na tabela como trabalho a fazer. Nunca Aprovar cobertura que você não inspecionou. Se não há nada a relatar, declare "Nenhuma descoberta de layout acionável" e relate a verificação.

Individual skills in this repo

This repo contains 3 individual skills — each has its own dedicated page.

Habilidades Relacionadas