iconfever

iconfever 是做什麼的？

Crie uma identidade reconhecível em tamanho pequeno e entregue o kit completo. Responda no idioma do usuário. Um render bonito é uma etapa da produção; o resultado inclui alternativas visuais, variantes e fontes editáveis.

Contrato de entrega

Para um novo ícone ou uma revisão ampla, o padrão é o kit completo de delivery.md. Só reduza esse conjunto quando o usuário pedir uma entrega mais restrita. Em um ajuste pontual, atualize o que foi afetado e preserve as versões coerentes; não reinicie a exploração sem necessidade.

Antes de desenhar, registre em icon-spec.json o modo de entrega, as plataformas e os arquivos esperados. Planeje desde o início a contraparte vetorial e a versão pequena mesmo quando o acabamento principal for gerado em raster.

• Conceitos: três propostas efetivamente desenhadas, com metáforas ou construções diferentes, em uma prancha comparativa. Nomes e descrições de propostas descartadas não cumprem essa etapa.
• Variantes do escolhido: principal, gráfica/plana, clara, escura, monocromática e pequena/favicon. Preserve os elementos que tornam o símbolo reconhecível.
• Formatos: SVG verdadeiro e editável, mais PNGs; render material adicional quando fizer sentido. Um SVG com PNG embutido não cumpre a entrega vetorial.
• Tamanhos: exports para usos distintos. Três PNGs do mesmo render em resoluções diferentes continuam sendo uma única variante.
• Revisão e handoff: prancha de alternativas, prancha final, contrato de direção, inventário dos arquivos e instruções curtas de uso.

Se já houver uma marca aprovada, preserve seu contorno: compare três aplicações ou tratamentos da mesma marca, identificados como tal. Não invente três logos para cumprir a contagem. Se uma limitação real impedir algum item, registre-o como pendente e explique; não declare o kit completo nem troque o escopo silenciosamente por uma imagem.

Contexto e referências

1. Descubra a proposta, o público, a personalidade e o uso do ícone. Leia os arquivos de identidade e os tokens relevantes do projeto: variáveis CSS, tema, componentes, ícones existentes, manifesto e assets. Registre os caminhos que sustentam as decisões. Se houver um design no Figma e acesso, aproveite os tokens e as imagens disponíveis.
2. Diferencie a função: ícone principal de app, favicon, símbolo de uma funcionalidade, mascote ou pictograma de navegação. O acabamento de um launcher não deve ser aplicado automaticamente a controles de 16–24 px.
3. Leia o atlas visual e o estudo das referências. Abra as imagens relevantes antes de desenhar. No acervo privado, consulte references/images/index.json, as duas folhas overview e ao menos três originais: um próximo à direção escolhida, um de construção/material diferente e um que mostre aplicação pequena. Registre o que extraiu de cada um em referenceObservations; folhas já abertas nesta sessão podem ser registradas como tal. Na distribuição pública, use o atlas, o estudo e as referências do projeto; o exemplo autoral ilustra uma aplicação, sem ser modelo obrigatório. Resolva caminhos a partir desta skill.
4. Prioridade: pedido explícito atual → identidade/tokens do produto → linguagem das referências → padrões desta skill. Extraia princípios de forma, luz e material; desenvolva outra silhueta e metáfora para o produto. Cores, gatos e fundos roxos das referências não são padrões universais.

Se faltar algo decisivo e impossível de inferir, faça uma pergunta curta. Caso contrário, declare a hipótese e avance. Não invente um design system existente: diferencie tokens encontrados, cores derivadas e escolhas propostas.

Defina a direção

Escreva um icon-spec.json enxuto junto dos entregáveis, usando o contrato de direção. Para uma edição pequena, atualize o contrato existente em vez de abrir um processo novo.

Para grids, padding, espessuras e requisitos de exportação, leia geometria, escala e destinos. Distinga as unidades do arquivo, do layout e da plataforma; uma convenção de ícones UI não determina as proporções de um launcher.

• Relacione a metáfora ao benefício do produto, além do nome literal da categoria.
• Escolha uma família principal do atlas. Combine detalhes de outra apenas se o resultado mantiver uma hierarquia clara.
• Mapeie tokens para papéis: base, símbolo, luz, sombra e acento. Derive variações tonais da marca; preserve o significado de cores de erro/sucesso.
• Fixe proporções, espessura, perspectiva, material, luz, olhos/expressão quando houver, margens e detalhe mínimo. Em um conjunto, isso constitui o contrato compartilhado.
• Descreva a assinatura visual que deve sobreviver nas variantes: contorno, recorte, proporção, gesto ou expressão. Especifique também o que pode desaparecer na redução.
• Separe arte de apresentação (squircle e sombra sobre fundo) de arquivos de plataforma. Não exporte o fundo preto de uma prancha como parte do ícone.

Produza as três propostas em fidelidade suficiente para comparar silhueta, relação com o produto e leitura pequena; SVGs rápidos são adequados para explorar antes de investir em material. Salve os conceitos individualmente e monte uma prancha. Recomende um e continue com autonomia quando o contexto permitir; peça escolha somente quando o usuário quiser participar ou faltar uma decisão de marca decisiva. Uma direção já escolhida dispensa novas metáforas: complete as aplicações e variantes dessa direção.

Produza os assets

Leia as rotas de produção e use os recursos reais do ambiente:

• Vetor: SVG autoral para silhuetas, marcas, mascotes simples, rabiscos e materiais representáveis com gradientes. Use formas editáveis, viewBox e IDs que não colidam ao integrar múltiplos SVGs.
• Raster: quando o usuário pedir imagem gerada ou o material exigir textura/render elaborado, use uma ferramenta de geração disponível. Envie referências visuais quando a ferramenta aceitar. Gere o ícone isolado e componha os exports corretamente. Não presuma que Codex ou Claude Code dispõem do mesmo gerador.
• Híbrido: use um SVG de composição como base para um render de material, preservando geometria e paleta. Mantenha clara a origem de cada arquivo.

Sem gerador, produza o kit vetorial e seus PNGs com os recursos disponíveis. Uma exigência essencial de material que não puder ser satisfeita continua pendente, com composição e prompt preservados. Quando usar gerador, conserve seu original e desenhe também o SVG gráfico complementar, mantendo a mesma identidade. Não prometa que esse vetor reproduz cada reflexo do raster. Não rotule prompt, mockup ou bitmap embutido como render final ou vetor puro.

Construa clara, escura e monocromática de propósito: ajuste os papéis de cor e luz sem mudar a assinatura. Monocromia deve funcionar como silhueta de uma cor sobre transparência. Simplifique detalhes, abra recortes e ajuste peso na versão pequena; não entregue só a redução automática de uma cena complexa.

Em conjuntos, finalize primeiro um exemplar que fixe o estilo; depois aplique o contrato aos demais. Preserve os mesmos papéis de cor, câmera, escala percebida e linguagem de materiais. Evite fazer cada item parecer de um autor diferente.

Revise visualmente

Renderize e abra a prancha comparativa e a prancha final com todas as variantes, em fundo claro, escuro e quadriculado. Confira as menores aplicações em 16/32 px e o ícone de app em 48/64/128 px, conforme destino. Compare raster e vetor lado a lado para detectar mudança de identidade. O helper abaixo gera HTML autossuficiente para SVG/PNG, sem dependências externas:

python "<pasta-da-skill>/scripts/icon_preview.py" "<pasta-dos-icones>" --out "<pasta-de-saida>/preview.html" --sizes 16 32 64 128

O helper verifica estrutura básica; ele não renderiza PNG de SVG, não mede contraste e não aprova qualidade visual. Abra o HTML em um navegador ou use o renderizador disponível para criar uma prancha PNG e inspecioná-la. Em uma sessão sem navegador visível, capture o HTML com um navegador headless instalado e abra a captura. Se não puder ver o render, declare a revisão visual pendente. ICO não entra na prancha: inspecione suas camadas separadamente quando esse formato fizer parte da entrega.

Para um kit grande, use --compact com um arquivo por variante; não repita cada resolução da mesma arte. Capture a altura total da página ou faça pranchas menores, sem omitir o final. Uma captura completa do helper pode cumprir o papel de prancha final.

Corrija falhas observadas antes de entregar:

• A silhueta e a metáfora sobrevivem à redução? Há um único foco reconhecível?
• Olhos, recortes e traços continuam separados? O símbolo não depende de texto minúsculo, textura ou brilho para existir?
• A paleta se parece com o produto? O símbolo se destaca da base nos temas reais? Para controles informativos, verifique contraste conforme o contexto de acessibilidade; não infira contraste pelo nome do token.
• O alinhamento é óptico, o peso é consistente e sombras/filtros não são cortados?
• O ícone respeita o enquadramento e a máscara do destino? A variante pequena foi simplificada quando necessário?
• As variantes e os membros da família preservam a identidade e se distinguem entre si?
• O efeito tem correspondência com as referências escolhidas? Borda, brilho, textura ou sombra estão sustentando o material ou só decorando um pictograma genérico?

Mude apenas os pontos que falharam e revise novamente. Se duas tentativas no mesmo caminho não resolverem a mesma falha, simplifique a construção ou informe a limitação, sem um ciclo de geração sem fim.

Exporte e integre

Leia o kit completo e os destinos. Entregue o núcleo padrão e acrescente os arquivos necessários às plataformas identificadas. Confira documentação oficial atual quando houver requisitos de plataforma. Não misture o master, o mockup e o asset já preparado para máscara.

Confira cada item do inventário de entrega em icon-spec.json: arquivo existente, papel correto, formato real e revisão realizada. Entregue o kit em uma pasta organizada e um ZIP com caminhos relativos; o ZIP não deve conter perfis de navegador, dependências nem imagens privadas de referência. Para raster gerado, registre prompt e referências usadas. Nomeie arquivos por função e variante.

Integre nos caminhos e convenções do projeto quando isso fizer parte do pedido; confirme que manifesto/imports apontam para arquivos existentes. Preserve acessibilidade: imagem decorativa sem anúncio duplicado; controle com nome acessível; símbolo informativo com alternativa textual.

Ao concluir, mostre a comparação e a proposta recomendada, informe o caminho absoluto da pasta e do ZIP, e liste as variantes/formatos entregues. Resuma o vínculo com os tokens e a validação efetiva. Diferencie arquivos prontos de pendências. Não substitua os arquivos por uma descrição do que faria.