Esboçador de Mockups HTML

Esboço

Use esta habilidade quando o usuário quiser ver uma direção de design antes de se comprometer com uma — explorando uma ideia de UI/UX como maquetes HTML descartáveis. O objetivo é gerar 2-3 variantes interativas para que o usuário possa comparar direções visuais lado a lado, não produzir código entregável.

Carregue esta habilidade quando o usuário disser coisas como "esboce esta tela", "mostre-me como X poderia parecer", "compare layout A vs B", "dê-me 2-3 opiniões sobre esta UI", "deixe-me ver algumas variantes", "faça uma maquete disto antes de eu construir".

Quando NÃO usar

• O usuário quer um componente de produção — use claude-design ou construa-o adequadamente
• O usuário quer um artefato HTML refinado de uso único (página de destino, apresentação) — claude-design
• O usuário quer um diagrama — excalidraw, architecture-diagram
• O design já está definido — apenas construa-o

Se o usuário tiver o sistema GSD completo instalado

Se gsd-sketch aparecer como uma habilidade irmã (instalado via npx get-shit-done-cc --hermes), prefira gsd-sketch para o fluxo de trabalho completo: pasta persistente .planning/sketches/ com MANIFEST, análise de modo frontier, auditorias de consistência entre esboços passados e integração com o resto do GSD. Esta habilidade é a versão leve e autônoma — esboços únicos sem a máquina de estado.

Método principal

entrada  →  variantes  →  comparação frente a frente  →  escolher vencedor (ou iterar)

1. Entrada (pule se o usuário já forneceu o suficiente)

Antes de gerar variantes, obtenha três coisas — uma pergunta de cada vez, não todas de uma vez:

1. Sensação. "Como isto deve parecer? Adjetivos, emoções, uma vibração." — "calmo, editorial, como o Linear" diz mais do que "minimalista".
2. Referências. "Quais aplicativos, sites ou produtos capturam a sensação que você está imaginando?" — referências reais superam descrições abstratas.
3. Ação central. "Qual é a coisa mais importante que um usuário faz nesta tela?" — as variantes devem todas servir bem a isto; se não, são apenas decoração.

Reflita brevemente sobre cada resposta antes da próxima pergunta. Se o usuário já forneceu todos os três de antemão, pule diretamente para as variantes.

2. Variantes (2-3, nunca 1, raramente 4+)

Produza 2-3 variantes de uma só vez. Cada variante é um arquivo HTML completo e autônomo. Não descreva variantes — construa-as. O objetivo é a comparação.

Cada variante deve adotar uma postura de design diferente, não valores de pixels diferentes. Três bons eixos de variação:

• Densidade: compacta / arejada / ultra-densa (escolha dois polos contrastantes)
• Ênfase: conteúdo primeiro / ação primeiro / ferramenta primeiro
• Estética: editorial / utilitária / lúdica
• Layout: coluna única / barra lateral / painel dividido
• Fundação: baseado em cartões / conteúdo simples / estilo documento

Escolha um eixo e destaque as diferenças a partir dele. Duas variantes que diferem apenas na cor de destaque são esforço desperdiçado — o usuário não consegue distingui-las.

Nomeação de variantes: descreva a postura, não o número.

esbocos/
├── 001-calm-editorial/
│   ├── index.html
│   └── README.md
├── 001-utilitarian-dense/
│   ├── index.html
│   └── README.md
└── 001-playful-split/
    ├── index.html
    └── README.md

3. Torne-os HTML reais

Cada variante é um único arquivo HTML autocontido:

• <style> inline — sem etapa de build, sem CSS externo
• Fontes do sistema ou uma Google Font via <link>
• Tailwind via CDN (<script src="https://cdn.tailwindcss.com"></script>) é aceitável
• Conteúdo falso realista — frases reais, nomes reais, não "Lorem ipsum"
• Interativo: links clicáveis, hovers reais, pelo menos uma transição de estado (abrir/fechar, filtrar, alternar). Uma imagem estática congelada é um esboço pior do que um animado desleixado.

Abra no navegador. Se parecer quebrado, corrija antes de mostrar ao usuário.

Verifique visualmente as variantes — use as ferramentas de navegador do Hermes. Não apenas escreva HTML e torça para que renderize; carregue cada variante e olhe para ela:

browser_navigate(url="file:///caminho/absoluto/para/esbocos/001-calm-editorial/index.html")
browser_vision(question="Este layout parece limpo e legível? Há algum bug visível (texto sobreposto, elementos sem estilo, imagens quebradas)?")

browser_vision retorna uma descrição da IA do que está realmente na página, mais um caminho de captura de tela — detecta bugs de layout que a inspeção pura do código fonte não percebe (por exemplo, uma importação de fonte que falhou silenciosamente, um contêiner flex que colapsou). Corrija e navegue novamente até que cada variante pareça correta.

Reset CSS padrão + pilha de fontes do sistema para início rápido:

<style>
  * { box-sizing: border-box; margin: 0; padding: 0; }
  body {
    font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto,
                 "Helvetica Neue", Arial, sans-serif;
    -webkit-font-smoothing: antialiased;
    color: #1a1a1a;
    background: #fafafa;
    line-height: 1.5;
  }
</style>

4. README da variante

O README.md de cada variante responde:

## Variante: {stance name}

### Postura de design
Uma frase sobre o princípio que impulsiona esta variante.

### Decisões-chave
- Layout: ...
- Tipografia: ...
- Cor: ...
- Interação: ...

### Compensações
- Pontos fortes: ...
- Pontos fracos: ...

### Mais adequado para
- O tipo de usuário ou caso de uso que esta variante realmente atende

5. Comparação frente a frente

Após todas as variantes serem construídas, apresente-as como uma comparação. Não apenas liste — opine:

## Três visões sobre a tela inicial

| Dimensão | Calmo editorial | Utilitário denso | Lúdico dividido |
|-----------|----------------|-------------------|---------------|
| Densidade | Baixa | Alta | Média |
| Visibilidade da ação principal | Baixa | Alta | Média |
| Legibilidade de varredura | Alta | Média | Baixa |
| Sensação | Calmo, confiável | Nítido, como ferramenta | Convidativo, energético |

**Minha opinião:** Utilitário denso para usuários avançados, calmo editorial para públicos focados em conteúdo. Lúdico dividido é o mais fraco — tenta fazer ambos e não se compromete com nenhum.

Deixe o usuário escolher um vencedor, ou combinar dois em um híbrido, ou pedir outra rodada.

Tematização (quando o projeto tem uma identidade visual)

Se o usuário tiver um tema existente (cores, fontes, tokens), coloque os tokens compartilhados em esbocos/temas/tokens.css e use @import em cada variante. Mantenha os tokens mínimos:

/* esbocos/temas/tokens.css */
:root {
  --color-bg: #fafafa;
  --color-fg: #1a1a1a;
  --color-accent: #0066ff;
  --color-muted: #666;
  --radius: 8px;
  --font-display: "Inter", sans-serif;
  --font-body: -apple-system, BlinkMacSystemFont, sans-serif;
}

Não coloque tokens demais em um esboço descartável — três cores e uma fonte geralmente são suficientes.

Barra de interatividade

Um esboço é interativo o suficiente quando o usuário pode:

1. Clicar em uma ação principal e algo visível acontecer (mudança de estado, modal, aviso, finta de navegação)
2. Ver uma transição de estado significativa (filtrar uma lista, alternar um modo, abrir/fechar um painel)
3. Passar o mouse sobre affordances reconhecíveis (botões, linhas, abas)

Mais do que isso é excesso de engenharia para algo descartável. Menos do que isso é uma captura de tela.

Modo Frontier (escolhendo o que esboçar em seguida)

Se já existirem esboços e o usuário disser "o que devo esboçar em seguida?":

• Lacunas de consistência — duas variantes vencedoras de esboços diferentes fizeram escolhas independentes que ainda não foram compostas juntas
• Telas não esboçadas — referenciadas, mas nunca exploradas
• Cobertura de estados — o caminho feliz foi esboçado, mas não os estados vazio / carregando / erro / 1000 itens
• Lacunas responsivas — validado em um viewport; será que se mantém em mobile / ultrawide?
• Padrões de interação — existem layouts estáticos; transições, arrastar, comportamento de rolagem não existem

Proponha 2-4 candidatos com nome. Deixe o usuário escolher.

Saída

• Crie esbocos/ (ou .planning/sketches/ se o usuário estiver usando convenções GSD) na raiz do repositório
• Um subdiretório por variante: NNN-nome-da-postura/index.html + README.md
• Diga ao usuário como abri-los: open esbocos/001-calm-editorial/index.html no macOS, xdg-open no Linux, start no Windows
• Mantenha as variantes descartáveis — um esboço que você sentiu necessidade de preservar deve ser promovido ao código real do projeto, não curado como um recurso

Sequência típica de ferramentas para uma variante:

terminal("mkdir -p esbocos/001-calm-editorial")
write_file("esbocos/001-calm-editorial/index.html", "<!doctype html>...")
write_file("esbocos/001-calm-editorial/README.md", "## Variante: Calmo editorial\n...")
browser_navigate(url="file://$(pwd)/esbocos/001-calm-editorial/index.html")
browser_vision(question="Como isso parece? Algum problema óbvio de layout?")

Repita para cada variante e então apresente a tabela de comparação.

Atribuição

Adaptado do fluxo de trabalho /gsd-sketch do projeto GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). O sistema GSD completo inclui estado persistente de esboço, referências de padrões de tema/variante e fluxos de trabalho de auditoria de consistência; instale com npx get-shit-done-cc --hermes --global.