Sketch
Use esta skill quando o usuário quiser ver uma direção de design antes de se comprometer com uma — explorando uma ideia de UI/UX como protótipos HTML descartáveis. O objetivo é gerar de 2 a 3 variantes interativas para que o usuário possa comparar direções visuais lado a lado, e não produzir código para envio.
Carregue esta skill quando o usuário disser coisas como "esboce esta tela", "me mostre como X poderia ser", "compare layout A vs B", "me dê 2 a 3 versões desta UI", "deixe-me ver algumas variantes", "prototipe isto antes de eu construir".
Quando NÃO usar esta skill
- O usuário quer um componente de produção — use
claude-designou construa adequadamente - O usuário quer um artefato HTML polido e único (landing page, deck) —
claude-design - O usuário quer um diagrama —
excalidraw,architecture-diagram - O design já está definido — apenas construa
Se o usuário tiver o sistema GSD completo instalado
Se gsd-sketch aparecer como uma skill irmã (instalada via npx get-shit-done-cc --hermes), prefira gsd-sketch para o fluxo de trabalho completo: diretório .planning/sketches/ persistente com MANIFEST, análise em modo frontier, auditorias de consistência entre esboços passados e integração com o restante do GSD. Esta skill é a versão autônoma e leve — esboços avulsos sem a máquina de estado.
Método principal
intake → variantes → comparação direta → escolher vencedor (ou iterar)
1. Intake (pule se o usuário já forneceu informações suficientes)
Antes de gerar variantes, obtenha três coisas — uma pergunta de cada vez, não todas de uma vez:
- Sensação. "Qual deve ser a sensação? Adjetivos, emoções, uma vibe." — "calmo, editorial, como Linear" diz mais do que "minimalista".
- Referências. "Quais apps, sites ou produtos capturam a sensação que você está imaginando?" — referências reais são melhores que descrições abstratas.
- Ação principal. "Qual é a coisa mais importante que um usuário faz nesta tela?" — as variantes devem todas atender bem a isso; 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 direto para as variantes.
2. Variantes (de 2 a 3, nunca 1, raramente 4+)
Produza de 2 a 3 variantes de uma só vez. Cada variante é um arquivo HTML completo e independente. Não descreva variantes — construa-as. O objetivo é a comparação.
Cada variante deve adotar uma postura de design diferente, não valores de pixel diferentes. Três bons eixos de variantes:
- Densidade: compacto / arejado / ultra-denso (escolha dois polos contrastantes)
- Ênfase: conteúdo primeiro / ação primeiro / ferramenta primeiro
- Estética: editorial / utilitário / lúdico
- Layout: coluna única / barra lateral / painel dividido
- Fundamentação: baseado em cartões / conteúdo puro / estilo documento
Escolha um eixo e explore 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 das variantes: descreva a postura, não o número.
sketches/
├── 001-calm-editorial/
│ ├── index.html
│ └── README.md
├── 001-utilitarian-dense/
│ ├── index.html
│ └── README.md
└── 001-playful-split/
├── index.html
└── README.md
3. Torne-as HTML real
Cada variante é um único arquivo HTML autocontido:
<style>inline — sem etapa de build, sem CSS externo- Fontes do sistema ou uma fonte do Google via
<link> - Tailwind via CDN (
<script src="https://cdn.tailwindcss.com"></script>) é aceitável - Conteúdo fictício 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 pior resultado do que um esboço animado e imperfeito.
Abra em um navegador. Se parecer quebrado, corrija antes de mostrar ao usuário.
Verifique visualmente as variantes — use as ferramentas de navegador do Hermes. Não escreva apenas HTML e espere que renderize; carregue cada variante e olhe para ela:
browser_navigate(url="file:///caminho/absoluto/para/sketches/001-calm-editorial/index.html")
browser_vision(question="Este layout parece limpo e legível? Algum bug visível (texto sobreposto, elementos sem estilo, imagens quebradas)?")
browser_vision retorna uma descrição de IA do que realmente está na página, além de um caminho de screenshot — detecta bugs de layout que a inspeção pura do código-fonte não captura (ex.: uma importação de fonte que falhou silenciosamente, um flex container que colapsou). Corrija e navegue novamente até que cada variante pareça correta.
Reset CSS padrão + pilha de fontes do sistema para inicialização rápida:
<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: {nome da postura}
### Postura de design
Uma frase sobre o princípio que orienta esta variante.
### Principais escolhas
- Layout: ...
- Tipografia: ...
- Cor: ...
- Interação: ...
### Trade-offs
- Forte em: ...
- Fraco em: ...
### Melhor para
- O tipo de usuário ou caso de uso que esta variante realmente atende
5. Comparação direta
Depois que todas as variantes forem construídas, apresente-as como uma comparação. Não apenas liste — opine:
## Três versões da tela inicial
| Dimensão | Editorial calmo | Utilitário denso | Dividido lúdico |
|----------|-----------------|------------------|-----------------|
| Densidade | Baixa | Alta | Média |
| Visibilidade da ação primária | Baixa | Alta | Média |
| Escaneabilidade | Alta | Média | Baixa |
| Sensação | Calmo, confiável | Afiado, como ferramenta | Convidativo, energético |
**Minha opinião:** Utilitário denso para usuários avançados, editorial calmo para públicos focados em conteúdo. Dividido lúdico é 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 tem um tema existente (cores, fontes, tokens), coloque tokens compartilhados em sketches/themes/tokens.css e faça @import deles em cada variante. Mantenha os tokens mínimos:
/* sketches/themes/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 super-tokenize um esboço descartável — três cores e uma fonte geralmente são suficientes.
Barra de interatividade
Um esboço é suficientemente interativo quando o usuário pode:
- Clicar em uma ação primária e algo visível acontecer (mudança de estado, modal, toast, fingimento de navegação)
- Ver uma transição de estado significativa (filtrar uma lista, alternar um modo, abrir/fechar um painel)
- Passar o mouse em affordances reconhecíveis (botões, linhas, abas)
Mais do que isso é engenharia excessiva para algo descartável. Menos do que isso é uma captura de tela.
Modo frontier (escolhendo o que esboçar em seguida)
Se esboços já existem e o usuário diz "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 — caminho feliz esboçado, mas não vazio / carregando / erro / 1000 itens
- Lacunas responsivas — validado em um viewport; será que se mantém em mobile / ultrawide?
- Padrões de interação — layouts estáticos existem; transições, arrastar, comportamento de rolagem não
Proponha de 2 a 4 candidatos nomeados. Deixe o usuário escolher.
Saída
- Crie
sketches/(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 sketches/001-calm-editorial/index.htmlno macOS,xdg-openno Linux,startno Windows - Mantenha as variantes descartáveis — um esboço que você sentiu necessidade de preservar deve ser promovido para o código real do projeto, não curado como um ativo
Sequência típica de ferramentas para uma variante:
terminal("mkdir -p sketches/001-calm-editorial")
write_file("sketches/001-calm-editorial/index.html", "<!doctype html>...")
write_file("sketches/001-calm-editorial/README.md", "## Variante: Editorial calmo\n...")
browser_navigate(url="file://$(pwd)/sketches/001-calm-editorial/index.html")
browser_vision(question="Como está a aparência? Algum problema de layout óbvio?")
Repita para cada variante e, em seguida, apresente a tabela de comparação.
Atribuição
Adaptado do fluxo /gsd-sketch do projeto GSD (Get Shit Done) — MIT © 2025 Lex Christopherson (gsd-build/get-shit-done). O sistema GSD completo inclui estado de esboço persistente, referências de padrões de tema/variante e fluxos de auditoria de consistência; instale com npx get-shit-done-cc --hermes --global.