jamesonedge/senior-design-review

Revisão de design sênior

Transforme um vago "melhore isso" em uma decisão de design testável. A saída é uma crítica estruturada que cita arquivos reais, tokens e padrões de referência, seguida por uma especificação que um engenheiro pode implementar.

Quando usar

Use esta skill quando o usuário pedir para:

• revisar, criticar ou "testar a pressão" de uma tela, fluxo ou componente existente;
• avaliar uma proposta escrita por outra pessoa (por exemplo, um designer júnior ou outro agente);
• decidir o que cortar, adicionar, revisar ou manter antes da implementação;
• corrigir um fluxo mobile a partir de capturas de tela.

Quando não usar

• Correções pequenas e locais, como "aumente o padding neste card" ou "mude este rótulo para 'Salvar'". Faça a alteração diretamente; uma revisão completa é ruído.
• Construir um protótipo interativo. Use um fluxo de trabalho de mockup interativo; esta skill pode alimentá-lo.
• Revisão de código não relacionado a UI, ajuste de desempenho ou design de back-end.
• Estratégia de marca ou marketing sem interface concreta.

Entradas

Reúna o que o repositório ou o usuário pode fornecer com segurança. Entradas faltantes são listadas como perguntas em aberto, nunca inventadas.

1. Tokens de design (cor, tipografia, espaçamento, raio, movimento) — caminhos de arquivo.
2. O(s) componente(s) canônico(s) existente(s) que o alvo deve se assemelhar.
3. Um exemplo aprovado anteriormente de trabalho semelhante, se existir (opcional, útil).
4. A implementação alvo e/ou capturas de tela.
5. Restrições conhecidas da plataforma (modelo de navegação, convenções do SO, alvos mínimos).
6. A reclamação do usuário, citada textualmente quando possível.

Um formulário de contexto para preenchimento está em templates/context.md.

Fluxo de trabalho

1. Elabore uma proposta inicial explícita

Antes de qualquer crítica, escreva a proposta usando templates/proposal.md: problema, pontos de dor citados, princípios de design, um esboço de arquitetura da informação, ações e perguntas em aberto. Se o usuário forneceu uma proposta, use a deles inalterada como entrada.

2. Execute a revisão como uma passagem nova

O revisor lê, nesta ordem: tokens, componente canônico, exemplo anterior, implementação/capturas de tela alvo, restrições da plataforma, e só então a proposta. Ler as evidências primeiro evita ancoragem na estrutura da proposta.

• Se seu runtime puder iniciar um contexto genuinamente separado (um sub-agente ou nova sessão sem histórico compartilhado), use-o e diga isso.
• Caso contrário, execute uma passagem separada você mesmo e rotule-a honestamente: "Passagem separada de agente único — não é revisão por pares independente."

A persona do revisor é uma lente de qualidade (um designer de produto sênior exigente). Nunca reivindique histórico de emprego, credenciais ou anos de experiência em nome da persona.

3. Escreva a revisão

Use templates/review.md. Seções:

• TL;DR — três a cinco linhas: veredito e a mudança mais importante.
• A. Crítica estrutural — esta é a tela/fluxo correto?
• B. Arquitetura da informação e hierarquia
• C. Semântica de ação — primária, secundária, destrutiva, desfazer, nomenclatura.
• D. Mecânica e gestos — toques, deslizes, arrastar, teclado, descobribilidade.
• E. Visual e movimento — tokens, ritmo, densidade, transições.
• F. Acessibilidade e internacionalização
• G. Perguntas em aberto — mire em cinco, mas inclua apenas as significativas.
• H. Especificação refinada mais o registro Corte / Adicione / Revise / Mantenha.

Orientação detalhada para cada lente está em references/review-lenses.md. A lista de verificação de acessibilidade e i18n está em references/accessibility-i18n.md.

Regras que tornam a revisão digna de leitura

• Teste a pressão; não carimbe. Toda afirmação precisa de uma referência específica: um caminho de arquivo, nome de token, nome de componente, região de captura de tela ou um padrão de referência nomeado (por exemplo, "deslizar para arquivar do iOS Mail").
• Sem platitudes. "Melhorar a hierarquia visual" não é um achado. "A data 'Vencimento' usa text.secondary no mesmo tamanho do título, então o prazo fica invisível à primeira vista" é.
• Sem cortes forçados. Se a estrutura atual está correta, diga e registre um Mantenha fundamentado. Mudar por mudar é um defeito.
• Sem medições inventadas. Não declare taxas de contraste, níveis de aprovação/reprovação WCAG ou métricas de desempenho a menos que você as tenha calculado ou medido, e mostre como. Caso contrário, escreva "não medido — verifique com uma ferramenta de contraste".
• Cubra estados. Vazio, carregando, erro, offline, conteúdo longo e conteúdo muito curto.
• Sinais não baseados em cor. O status nunca deve depender apenas de cor.
• Caminhos de teclado e leitor de tela para cada ação, incluindo gestos personalizados.
• Expansão de texto (permita aproximadamente 30–40% mais caracteres para muitos idiomas) e layout da direita para a esquerda quando relevante.
• Alternativa de movimento reduzido para cada animação.

Opcional: compare com trabalho anterior

Se existir um exemplo aprovado anteriormente, adicione uma breve nota "Consistência com trabalho anterior" sob E ou H. Isso é útil, não obrigatório.

Saídas

• proposal.md (se você a redigiu)
• review.md contendo TL;DR, A–H e o registro
• Um breve resumo para o usuário: veredito, três principais mudanças e as perguntas em aberto que bloqueiam a implementação

Verificações de aceitação

Consulte references/review-lenses.md#acceptance-checks. Uma revisão falha se qualquer linha do registro não tiver motivo e referência, ou se declarar números não medidos como fato.

Aviso de licença

O aviso a seguir acompanha esta skill independente e seus arquivos de suporte.

Licença MIT

Copyright (c) 2026 jamesonedge

Permissão é concedida, gratuitamente, a qualquer pessoa que obtenha uma cópia
deste software e arquivos de documentação associados (o "Software"), para lidar
no Software sem restrição, incluindo, sem limitação, os direitos
de usar, copiar, modificar, mesclar, publicar, distribuir, sublicenciar e/ou vender
cópias do Software, e permitir que pessoas a quem o Software é
fornecido o façam, sujeito às seguintes condições:

O aviso de direitos autorais acima e este aviso de permissão devem ser incluídos em todas as
cópias ou partes substanciais do Software.

O SOFTWARE É FORNECIDO "COMO ESTÁ", SEM GARANTIA DE QUALQUER TIPO, EXPRESSA OU
IMPLÍCITA, INCLUINDO, MAS NÃO SE LIMITANDO ÀS GARANTIAS DE COMERCIALIZAÇÃO,
ADEQUAÇÃO A UM PROPÓSITO ESPECÍFICO E NÃO VIOLAÇÃO. EM NENHUM CASO OS
AUTORES OU DETENTORES DOS DIREITOS AUTORAIS SERÃO RESPONSÁVEIS POR QUALQUER REIVINDICAÇÃO, DANOS OU OUTRA
RESPONSABILIDADE, SEJA EM AÇÃO DE CONTRATO, ATO ILÍCITO OU DE OUTRA FORMA, DECORRENTE DE,
FORA DE OU EM CONEXÃO COM O SOFTWARE OU O USO OU OUTRAS NEGOCIAÇÕES NO
SOFTWARE.