Open Design Critique: revisão visual em cinco dimensões com evidência

ANÁLISE EDITORIAL

Uma crítica visual útil não começa com “gostei” ou “não gostei”. Ela começa identificando o artefato, a intenção e a evidência que sustenta cada conclusão. Open Design Critique transforma esse trabalho em um relatório HTML de cinco dimensões: consistência filosófica, hierarquia visual, execução de detalhes, funcionalidade e inovação. Cada nota precisa apontar elementos concretos, como classes, páginas, componentes ou decisões tipográficas.

A proposta não é certificar um design nem substituir teste de usabilidade, acessibilidade ou navegador. A Skill organiza uma revisão crítica de um artefato HTML existente e termina com três listas: o que preservar, o que corrigir e quais ajustes rápidos têm melhor relação entre esforço e impacto visual. O relatório serve para orientar uma próxima rodada, não para declarar que uma interface está pronta.

Imagem: Ilustração editorial exclusiva do Bastidores da IA sobre uma composição visual examinada por uma lente de cinco facetas. Não é captura de tela, interface real, logotipo oficial, gráfico de uma avaliação executada nem resultado produzido pela Skill.

O que esta Skill faz de verdade

O SKILL.md fixado no commit auditado pede um relatório autocontido em HTML. A saída inclui cabeçalho, veredito de uma linha, gráfico radar em SVG, cinco cartões de avaliação e listas consolidadas de preservação, correção e ganhos rápidos. CSS e SVG ficam embutidos no arquivo, sem biblioteca externa.

As cinco dimensões são independentes. Consistência filosófica verifica se uma direção visual permanece coerente nas decisões menores. Hierarquia pergunta se o olhar encontra primeiro, segundo e terceiro níveis sem instrução. Detalhe examina alinhamento, espaçamento, tipografia, molduras e casos de borda. Funcionalidade considera navegação, legibilidade, interação e uso previsto. Inovação procura decisões memoráveis que sirvam à intenção, sem premiar efeitos gratuitos.

A escala vai de zero a dez, com faixas qualitativas declaradas no arquivo. A Skill manda justificar cada nota com evidência e evitar inflação. Ela também instrui o agente a não elevar uma dimensão apenas porque outras partes ficaram boas. Isso reduz a tendência de produzir cinco elogios genéricos, mas a nota continua sendo julgamento editorial, não medição objetiva.

Para quem serve

Serve para designers, desenvolvedores front-end, equipes de conteúdo e responsáveis por produto que já têm uma página, apresentação ou protótipo em HTML e precisam decidir a próxima intervenção. É especialmente útil quando a discussão está presa em preferências pessoais e alguém precisa transformar “parece confuso” em observações reproduzíveis sobre ordem de leitura, consistência e comportamento.

Também pode apoiar a comparação entre duas variantes do mesmo artefato, desde que o escopo e os critérios sejam iguais. Nesse caso, preserve duas cópias, registre o objetivo de cada variante e exija evidência separada. A Skill não deve ser usada para comparar produtos diferentes como se uma média visual resumisse estratégia, público, conteúdo e desempenho.

Ela não é a ferramenta principal para auditar WCAG, originalidade de referências, qualidade de uma Skill ou construção de diagramas. O catálogo do Bastidores já tem páginas para esses fins. Open Design Critique se diferencia porque recebe um artefato HTML e devolve uma crítica visual estruturada em cinco dimensões, com radar e ações.

Compatibilidade e pré-requisitos

No projeto de origem, Critique é classificada como design template, modo prototype e plataforma desktop. O protocolo oficial de Skills e templates separa capacidades funcionais de formatos de renderização. Por isso, esta entrada aparece no catálogo de templates do Open Design e produz um artefato, em vez de funcionar como auditor autônomo instalado em qualquer host sem adaptação.

O commit auditado declara Open Design 0.20.3, Node.js da linha 24 e pnpm 10.33.2. Esses requisitos pertencem à execução do repositório completo. O arquivo textual pode ser lido por outros agentes, mas os campos od, o contrato <artifact> e a visualização integrada podem não existir fora do Open Design. Nesses ambientes, trate o arquivo como instrução portátil e valide como o host salva e abre HTML.

Antes do primeiro uso, tenha um HTML identificável, acesso de leitura à pasta e contexto sobre o objetivo do artefato. Se houver vários HTML, escolha um. A própria Skill manda perguntar qual arquivo será avaliado, não revisar todos silenciosamente. Um DESIGN.md ativo é opcional; quando existe, fornece tokens e direção para o relatório.

Instalação recomendada

Para quem usa uma distribuição do Open Design que já contém este commit, não há uma Skill isolada a instalar. O template critique já está em design-templates/critique. Abra o projeto, selecione o fluxo de crítica e confirme que o artefato certo está disponível. A documentação informa que o diretório de templates é relido pela API do daemon.

Para revisar a origem de forma reproduzível, use um clone separado e fixe o commit:

git clone https://github.com/nexu-io/open-design.git
cd open-design
git checkout 05f5b33ef59f078df10ac1125986e00e4a796cf3
pnpm install
pnpm tools-dev

Leia o guia de execução do repositório antes de iniciar. O guia de contribuição de templates registra que o comando od skills é somente leitura e que a antiga forma od skill add foi aposentada. Não invente um instalador isolado para este arquivo.

O ZIP do Bastidores é um espelho documental. Ele ajuda a comparar o SKILL.md, a licença e a origem, mas não inclui example.html, aplicativo, daemon, interface, dependências ou scripts. Ele não substitui o repositório oficial nem reproduz o Open Design.

Configuração antes do primeiro uso

Defina quatro itens: arquivo avaliado, objetivo, público e contexto de uso. Informe se é página, deck, protótipo ou relatório. Registre ambiente, tamanhos de tela relevantes, estado de navegação e limitações conhecidas. Sem isso, a dimensão de funcionalidade pode receber uma nota baseada em suposições.

Proteja dados. Remova chaves, dados pessoais, textos de clientes, URLs internas e comentários que não sejam necessários. Se o artefato carrega recursos externos, crie uma cópia controlada ou descreva o que não pode ser aberto. A revisão precisa citar evidência do arquivo autorizado, não explorar pastas vizinhas por conveniência.

Escolha se o agente pode apenas ler ou também abrir o HTML em navegador local. A leitura de código ajuda a localizar classes e regras. A verificação visual ajuda a observar hierarquia e quebra responsiva. Nenhuma delas autoriza edição. Peça relatório primeiro e deixe mudanças para uma etapa separada, revisável e reversível.

Primeiro uso seguro

Comece com um único arquivo e um pedido explícito: “Revise pagina.html nas cinco dimensões da Critique. Não altere arquivos. Cite classes, seções ou páginas. Separe o que preservar, corrigir e ajustar rapidamente. Se faltar contexto para funcionalidade, marque a lacuna”.

A Skill orienta a leitura do bloco <style> e de seis a oito blocos representativos. Isso é amostragem, não inspeção exaustiva. Em um deck longo, defina páginas críticas. Em uma landing page, inclua cabeçalho, proposta de valor, ação principal, prova, rodapé e estado móvel. Se uma falha aparecer apenas após interação, registre que o código sozinho não confirmou o comportamento.

Leia o relatório antes de aceitar as notas. Cada cartão precisa nomear evidência específica. Uma frase como “a hierarquia está fraca” não passa. Uma observação que cita dois títulos do mesmo peso competindo acima da dobra pode ser conferida. O guia do Bastidores sobre revisão de permissões de agentes ajuda a manter o escopo de leitura separado de edição e publicação.

Resultado esperado

O resultado esperado é um único arquivo HTML autocontido. No topo, ele identifica o artefato, a data, o revisor e um veredito curto. O gráfico radar mostra o formato relativo das cinco notas. Em seguida, cada dimensão traz faixa, nota, evidência e ao menos uma ação. As listas finais permitem levar os achados para uma rodada de refinamento.

O gráfico facilita encontrar um eixo fraco, mas não deve ser usado como pontuação de desempenho de uma pessoa. A média também não aparece como aprovação automática. Um design pode ser funcional e pouco inovador por decisão correta. Outro pode ser memorável e falhar em leitura ou navegação. O valor está na justificativa e na prioridade das ações.

Depois da revisão, converta apenas os itens aceitos em tarefas. Preserve a versão avaliada e vincule cada mudança ao achado correspondente. Rode novamente somente após alterações materiais. Repetir a crítica até obter notas altas incentiva ajuste ao avaliador, não necessariamente ao usuário.

Permissões e riscos

A Skill precisa ler o artefato e, dependendo do pedido, arquivos de estilo ou um DESIGN.md. Isso pode expor código proprietário, conteúdo inédito e diretrizes de marca. Restrinja a raiz, use cópia minimizada e evite conectar contas ou repositórios com escrita. O relatório pode reproduzir trechos ou nomes internos na evidência.

Notas visuais continuam sujeitas a viés cultural, preferência estética e contexto incompleto. A rubrica torna o julgamento mais legível, mas não o torna científico. Funcionalidade não substitui teste em navegador, dispositivos ou tecnologias assistivas. Hierarquia não prova compreensão. Inovação baixa não significa defeito.

O HTML gerado deve ser aberto como conteúdo não confiável até ser revisado. A regra da Skill proíbe CSS e JavaScript externos, mas o host e o artefato de entrada podem ter capacidades maiores. Use ambiente local isolado, não carregue segredos e não publique o relatório sem conferir o que foi incorporado.

Erros comuns

• Avaliar o arquivo errado: confirme caminho, versão e objetivo antes de pontuar.
• Dar nota sem evidência: cite classe, seção, página ou regra verificável.
• Confundir estilo com acessibilidade: rode auditoria específica e teste assistivo.
• Usar a média como aprovação: leia cada dimensão e o custo da falha.
• Premiar efeito gratuito: inovação precisa servir à direção escolhida.
• Revisar vários HTML de uma vez: escolha um ou crie avaliações separadas.
• Alterar durante a crítica: primeiro gere relatório, depois aprove mudanças.
• Tratar o ZIP local como aplicativo: ele é documental e não inclui o runtime.

Versão auditada e download local

A curadoria fixou o commit 05f5b33ef59f078df10ac1125986e00e4a796cf3, que declara a versão 0.20.3. Na consulta de 22/08/2026 às 12h, o repositório nexu-io/open-design tinha 90.346 estrelas e não estava arquivado. Estrelas indicam adoção observável, não auditoria de segurança ou garantia de qualidade.

A licença Apache-2.0 permite redistribuição sob suas condições. O ZIP local tem 9.376 bytes, contém somente SKILL.md, LICENSE e ORIGEM.md, e possui SHA-256 9877bb429dccbde8e9a7f9c06a0e05ea52abaac1a41fbc4b2990f5d32d4d6533. Os arquivos foram preservados sem adaptar o conteúdo oficial.

O diretório oficial também inclui um exemplo HTML, que não entrou no pacote próprio. Isso mantém o espelho estreito e documental. O botão do repositório oficial e o download local são ações separadas.

Resultado esperado e limite final

Open Design Critique é útil quando a equipe precisa sair de opiniões vagas e chegar a uma fila de decisões visuais verificáveis. O relatório deve deixar claro o que foi observado, por que recebeu determinada faixa e qual ação merece prioridade. O melhor resultado não é cinco notas altas, mas uma próxima rodada mais focada.

Considere a execução concluída quando cada dimensão tem evidência, as listas não se contradizem e as limitações do teste foram registradas. Antes de editar, valide os achados com objetivo, público, acessibilidade e comportamento real. Antes de publicar, faça revisão humana do artefato modificado.

Fontes primárias

• Repositório oficial nexu-io/open-design
• Diretório Critique no commit auditado
• SKILL.md oficial fixado
• Protocolo oficial de Skills e design templates
• Guia oficial de contribuição e instalação
• Versão e requisitos do pacote no commit
• Licença Apache-2.0 preservada no pacote