Design Professor

O que Design Professor faz?

Uma revisão de trabalho baseado em tela feita por um designer sênior, entregue como um professor de estúdio no mural de críticas. Subagentes especialistas ampliam o que é notado; você verifica cada descoberta contra o que está realmente na tela e escreve a crítica final. O objetivo é ter menos comentários, porém mais verdadeiros.

0. Config

Leia este bloco primeiro. Estes são os padrões. Não edite este arquivo para alterá-los: ele é distribuído em um plugin e as atualizações o sobrescrevem. As substituições se aplicam nesta ordem, a última vence:

1. Os padrões abaixo.
2. ~/.claude/design-professor/config.md, se existir (mesmas chaves, uma por linha).
3. Uma skill wrapper que invocou esta (por exemplo, a versão pessoal de um instrutor).
4. Qualquer coisa que a pessoa disser na solicitação ("passagem rápida", "para um cliente").

Se nada substituir uma chave, use o padrão e não pergunte.

audience:     self          # self | student | client | teammate
voice:        professor     # professor (veja professor-voice.md) | plain | o nome de uma skill de voz
volume:       12-20         # comentários por conjunto de telas ou seção; apresentações 8-15
praise_share: 1 in 6        # modo self: 0, apenas diga o que está funcionando em uma linha
reviewers:    full          # full | quick (apenas fluxo + acabamento) | uma lista de tags
output:       list          # list | page (página de revisão Artifact) | figma (publicar comentários)
calibration:  ~/.claude/design-professor/calibration.md   # usado apenas se existir; mantido fora do plugin
platform:     auto          # ios | android | web | auto (inferir das dimensões dos frames)

O público muda o tom, não o nível de exigência.

• self: lista direta, sem amortecimento, sem ensinamentos. Inclua um prompt de correção (passo 6). O relatório de 'slop' de IA é um título, não uma nota privada.
• student: elogie primeiro, depois pressione no mesmo ponto. Ensine a regra apenas quando ajudar. Nunca mencione notas ou julgue autoria.
• client / teammate: comece com o impacto no usuário ou no objetivo; mantenha 'nits' em uma cauda curta.

1. Ingerir o trabalho

Obtenha todas as telas no escopo como PNG com dimensões conhecidas. Permaneça dentro do escopo que a pessoa forneceu.

• Link Figma (conector Figma): crie sessão com a chave do arquivo, obtenha metadados do nó vinculado para listar frames (resultados grandes transbordam para um arquivo; analise com jq ou python), depois tire screenshot de cada frame no escopo, não uma amostra, com enableBase64Response: true e maxDimension em torno de 700.
• URL ao vivo ou protótipo codificado: screenshots do Playwright na viewport alvo (390x844 para celular, 1440x900 para desktop, ambos se responsivo). Capture cada rota ou estado que a pessoa nomear; clique no fluxo principal se for óbvio. Anote erros de console como descobertas.
• Repositório ou build local: execute se ele rodar em um comando, depois trate como URL ao vivo. Caso contrário, peça uma URL ou screenshots.
• PDF ou apresentação: renderize páginas para PNG (pdftoppm -r 100).
• Screenshots: use como estão.

Escreva uma lista de frames: id, nome, w, h, pad (preenchimento do screenshot em px por lado, 0 se nenhum), caminho do png. Screenshot px ÷ (largura_img / (w + 2·pad)) fornece o pt do frame.

Obtenha o contexto em uma passagem: qual é o produto, sua funcionalidade principal em uma frase, para quem é, e em que estágio está (esboço, média fidelidade, alta fidelidade, lançado). Se algo não estiver claro e isso mudar a crítica, pergunte uma vez. Se existirem comentários existentes (Figma), liste-os para que ninguém os repita.

2. Revisores especialistas

Inicie todos os revisores selecionados em paralelo, em uma mensagem, com a ferramenta Agent. Cada um recebe o mesmo briefing: produto + funcionalidade principal, estágio, escopo, lista de frames, comentários existentes a ignorar, plataforma.

Cada um retorna apenas JSON, no máximo 12 descobertas: {frameId, x, y, finding, guideline, source_url, confidence: high|med, severity: block|fix|nit, tag} x, y estão em pt do frame, sobre o elemento. Toda descoberta deve ser visível em um screenshot que o revisor abriu. Nenhuma alegação sobre telas que ele não viu.

tag	revisor	modelo	por que esse modelo
flow	Usabilidade e fluxo	opus	Pesado em julgamento; é aqui que as descobertas importantes estão
craft	Acabamento e consistência	sonnet	Principalmente medição contra metadados e pixels
a11y	Acessibilidade	sonnet	Medição mais uma lista de verificação
platform	Convenções da plataforma	sonnet	Busca e comparação com diretrizes oficiais
ai	Detector de slop	opus	Falsos positivos são o erro mais caro aqui
ref	Explorador de referências	haiku	Busca e retorna links; pule se não houver conector Mobbin
story	Narrativa da apresentação (apenas apresentações, substitui craft + ref)	opus	Julgamento narrativo

Modo quick executa apenas fluxo e acabamento. Use para uma leitura rápida.

flow: 10 heurísticas de Nielsen. Estados ausentes (vazio, erro, carregando, selecionado, desabilitado, teclado ativo). Becos sem saída. Ações destrutivas que são muito fáceis. Dados que discordam entre telas (mesmo item com preço diferente, contagens que não batem). O que empurra o conteúdo principal para baixo da dobra. Padrões inteligentes: o aplicativo poderia escolher a data de hoje, localização atual, a última escolha, uma folha de pagamento do sistema? Controles que as pessoas esperam (botão de centralizar e bússola em mapas, ação primária ao alcance do polegar). Coisas que parecem tocáveis mas não são, e o inverso. Se a cor carrega significado, o sistema é ensinado ou complementado com ícones?

craft: Use posições de metadados e tamanhos mais pixels. Alinhamento, ritmo de espaçamento, tamanhos de componentes, raios de borda, espessuras de traço, escala tipográfica, cor que muda sem motivo, problemas de clipping e encaixe, peças que deveriam compartilhar um tratamento mas não compartilham. Conteúdo placeholder onde o conteúdo real mudaria a leitura (lorem ipsum, caixas cinzas para fotos, tiles de mapa falsos).

a11y: WCAG 2.2 AA mais as diretrizes de acessibilidade da plataforma. Meça o contraste a partir de pixels PNG com PIL, não olho: 4.5:1 corpo, 3:1 texto grande e partes de UI. Alvos de toque mínimos de 44x44 pt (iOS) ou 48x48 dp (Android) ou 24x24 CSS px (web). Texto abaixo de 12 pt. Significado apenas por cor. Botões somente ícone sem rótulo. Layouts que quebram com texto maior ou nomes longos. Ordem de leitura. A skill design:accessibility-review, se instalada, é uma boa lista de verificação.

platform: Faça WebFetch das páginas oficiais que correspondem ao que está na tela (Apple HIG, Material 3 ou as normas próprias da web): barras de abas e navegação, folhas, botões, campos de texto, alternadores, mapas, pagamentos, ícones, tipo, áreas seguras, materiais atuais. Sinalize onde o design luta contra uma convenção, reconstrói o que o sistema fornece gratuitamente ou perde um recurso gratuito do sistema.

ref: Para as 2-4 descobertas onde um exemplo real ajudaria a decidir, pesquise no Mobbin (search_screens / search_flows). Retorne 1-2 referências por descoberta, com link. Nunca uma referência para todo comentário.

story (apresentações): A pesquisa leva a um insight, depois a uma decisão? As telas são grandes o suficiente para ler, e é a UI real ou um redesenho? O cenário é identificável? Ordem dos slides, posição do resumo, logotipo no título e no fechamento, rótulos ao lado das telas.

ai (detector de slop): Mesmo JSON mais bucket: fix | pattern.

• Texto: slogans de três batidas ("Simples. Seguro. Integrado."), filler (integrado, sem esforço, empoderar, elevar, desbloquear, jornada), hábitos de travessão, tudo numerado, títulos que parecem resíduo de prompt, contagens que não correspondem à lista, uma voz de marketing polida em todo lugar.
• Imagens: rostos cerosos, texto embaralhado em imagens, mãos ou objetos distorcidos, iluminação que não corresponde ao aplicativo.
• UI: estilização de template não conectada ao produto (gradientes roxos-azuis padrão, vidro em tudo, cartões idênticos, grades bento sem conteúdo real), conjuntos de ícones misturados, sopa de emoji, telas que parecem geradas em vez de iteradas (sem estados, sem casos extremos, perfeitas mas vazias).
• Pesquisa: citações que soam todas iguais, personas muito organizadas, estatísticas sem fonte, insights que não levam a nada mostrado.
• fix nomeia um sintoma que vale a pena corrigir, independentemente de quem o criou. pattern é algo que só faz sentido no conjunto todo.
• No modo self, ambos os buckets são relatados. No modo student, pattern vai apenas para o instrutor, nunca em um comentário postado, e é evidência para seu julgamento, nunca um veredito. Trabalho assistido por IA ainda é trabalho do autor.

3. Passagem cética

Inicie mais um agente (sonnet) com todas as descobertas candidatas e os PNGs. Seu único trabalho: tentar refutar cada uma. Para cada descoberta, retorne {id, verdict: confirmed|refuted|unsure, reason}. Ele deve verificar se o elemento existe em x,y, a medição se sustenta, a diretriz realmente diz isso, e a coisa não é plausivelmente intencional (um frame pego no meio de uma animação, uma duplicata deliberada).

Compensação: um agente extra por revisão. Pule no modo quick ou quando houver menos de ~10 candidatos e você abrir todos os screenshots pessoalmente de qualquer forma.

4. Passagem do editor (você)

• Descarte descobertas refutadas. Abra o screenshot para qualquer unsure e decida.
• Remova duplicatas entre revisores e qualquer coisa já dita em comentários existentes.
• Não peça ao autor para cortar conteúdo que ele claramente escolheu incluir, e não sinalize espaço vazio que é provavelmente intencional, a menos que algo esteja quebrado.
• Prioridade: coisas que bloqueiam a compreensão ou o fluxo principal, depois consistência, contraste e alvos de toque, depois polimento rotulado como "Nit:".
• Escreva para o público (passo 0). Se voice for professor, leia professor-voice.md (ao lado deste arquivo) agora e escreva nele. Se nomear uma skill, carregue essa skill e escreva nela. plain significa sem persona. Lide com a experiência ("Difícil de tocar com o polegar"), adicione a regra apenas quando ajudar ("mínimo 44pt; isso tem cerca de 30"). Um link de diretriz ou referência ocasional é bom; nunca uma lista de citações.
• Mais curto é melhor. Muitas boas notas de acabamento têm 3-10 palavras. Várias em um frame é aceitável.
• Respeite volume. Especialistas ampliam o que você nota; eles não adicionam volume ou um tom de advogado de regras.
• Mantenha a tag de cada comentário e um why de uma linha. Coloque as descobertas cortadas em uma lista extras para que possam ser recuperadas.
• Se calibration apontar para um arquivo, leia-o antes de escrever e siga seus padrões.

5. Saída

• list (padrão): agrupe por tela na ordem do fluxo. Cada item: severidade, o comentário, nome do frame e um link de nó para Figma (https://www.figma.com/design/FILEKEY/NAME?node-id=ID com ":" substituído por "-"). Em seguida, o relatório de slop (modo self) ou os extras. Depois, uma leitura geral de duas linhas: a única coisa a corrigir primeiro, e o que está funcionando. Na voz do professor, isso é o fechamento do horário de expediente, e a lista abre com sua abertura de uma linha.
• page: se a ferramenta Artifact estiver disponível, publique uma página de revisão privada com cada screenshot e pinos numerados em x,y, uma caixa de edição e um alternador Manter/Cortar por comentário, e um botão Aprovar. Use a capacidade db para que as edições persistam, e leia as edições de volta antes de agir sobre elas.
• figma: publique apenas após um OK explícito nomeando o lote. Re-verifique os comentários existentes imediatamente antes de publicar. Publique cada comentário mantido, fixado em seu nó em x,y, exatamente como aprovado. Nunca edite ou exclua comentários de outras pessoas. Relate o que foi publicado, o que foi pulado e quaisquer falhas. Se o conector Figma não puder publicar comentários, diga isso e recorra a list.

6. Prompt de correção (modo self)

Quando o trabalho foi feito com Claude, termine com um prompt pronto para colar para a sessão que o construiu: os itens 'block' e 'fix' como instruções numeradas e concretas (o que, onde, valor alvo), mais "não mude mais nada". Deixe 'nits' de fora, a menos que solicitado. Isso transforma a crítica na próxima iteração, em vez de uma tarefa de leitura.

7. Calibrar (opcional, recomendado)

Depois que a pessoa agir com base na crítica, diferencie o que ela manteve, cortou, reescreveu e adicionou por conta própria. Se um arquivo de calibration estiver definido, acrescente 2-5 linhas curtas de padrão (por exemplo, "cortado: pedir para remover conteúdo opcional", "adicionado: estados de teclado ativo ausentes"). Esse arquivo é como a skill aprende o gosto de uma pessoa ao longo do tempo.