onovich/RepoCover

O que RepoCover faz?

Crie uma prévia social específica do repositório que permaneça legível em tamanho de miniatura. Prefira composição determinística e editável em vez de um banner genérico gerado.

Invariantes do produto

• Entregar um raster exato de 1280×640, normalmente PNG, com menos de 1.000.000 bytes.
• Manter uma fonte editável, normalmente SVG, ao lado do raster.
• Fundamentar afirmações visíveis, métricas, capturas de tela e provas em evidências do repositório.
• Preservar a identidade do repositório em vez de impor um estilo único.
• Validar o tamanho completo e 320×160 em fundos claro e escuro.
• Tratar a criação de imagem e o upload para o GitHub como limites de autorização separados.
• Não implicar afiliação ou endosso do GitHub.

Carregar as referências corretas

Leia estes dois arquivos para cada capa:

• references/common-quality.md para composição universal e portões de rejeição.
• references/design-ledger-template.md para o registro de evidências, design e validação.

Em seguida, leia apenas a rota que se aplica:

• Leia references/source-material.md quando existirem capturas de tela, capturas de tempo de execução, logotipos, ilustrações, SVGs, sprites, texturas ou outros visuais significativos.
• Leia references/cold-start.md quando não existir captura de tela utilizável, captura de tempo de execução, marca registrada ou visual primário de propriedade do repositório.
• Leia references/version-regression.md ao atualizar uma capa existente, comparar candidatos ou gerar um lote versionado.

Não carregue uma rota irrelevante apenas porque ela existe. references/design-recipes.md é apenas um índice de compatibilidade para prompts mais antigos.

Fluxo de trabalho

1. Inspecionar e delimitar as evidências

Leia os arquivos AGENTS.md aplicáveis, o README, metadados de pacotes, caminhos de origem significativos, ativos visuais e qualquer prévia social existente. Identifique:

• nome do repositório e tarefa principal do usuário;
• uma declaração de valor concreta;
• no máximo três pontos de prova;
• a evidência de produto mais forte;
• identidade visual estabelecida e fatos secundários a excluir;
• modo de evidência: remote-static, local-static, build-tested ou runtime-tested.

Nunca implique que uma compilação, tempo de execução, cena ou teste foi executado quando apenas evidências estáticas foram inspecionadas. Se os requisitos de imagem do GitHub puderem ter mudado, verifique-os na documentação oficial do GitHub.

Para um repositório remoto, use as evidências públicas ou autenticadas do GitHub disponíveis para inspecionar seu README, árvore, manifestos, arquivos de origem significativos, prévia atual e ativos visuais mais fortes. Mantenha as saídas em um diretório durável voltado para o usuário e registre URLs de origem e limites de alegação. Se nenhum tempo de execução ou interface representativa puder ser alcançado, declare essa limitação em vez de fingir que a evidência remota é equivalente a uma prévia local funcional. Projetos locais visualizáveis, especialmente projetos web com uma interface existente, geralmente fornecem a evidência visual mais rica.

2. Escrever o ledger e escolher a rota

Crie um ledger de design a partir do modelo fornecido antes de desenhar. No mínimo, registre:

• Promessa, prova, excluir;
• modo de evidência e limites de alegação;
• diagnóstico de material de origem ou esqueleto semântico de cold-start;
• rota de produção e interpretação escolhida;
• decisões de material, função do ativo, topologia e linha;
• versão de saída, validação e veredito de promoção, quando aplicável.

Escolha a menor rota de produção que preserve a identidade:

• SVG nativo de código — preferido: ferramentas de desenvolvedor, diagramas, gráficos, logotipos, bibliotecas e sistemas visuais inferidos.
• Captura de tela ou híbrido de fonte: apenas quando um artefato de fonte autocontido permanece a prova mais clara após o diagnóstico.
• Ilustração híbrida: apenas quando a ilustração é central para a identidade do repositório; gere arte sem texto importante e sobreponha a redação exata em SVG.

Não invoque geração de imagem apenas para imitar um sistema vetorial estabelecido.

3. Construir e versionar a fonte editável

Padrão para docs/social-preview.svg e docs/social-preview.png, a menos que o repositório tenha uma convenção clara de ativos ou o usuário nomeie outro destino.

• Use um viewBox 1280 640 e um fundo de tela inteira.
• Mantenha o conteúdo essencial dentro de uma área segura externa de aproximadamente 72 px.
• Partição de cópia, prova de produto, legendas e assinatura em regiões que não se sobreponham.
• Use fontes do sistema, a menos que o repositório forneça uma fonte licenciada apropriada.
• Incorpore evidências locais ou reproduza-as com primitivas SVG determinísticas; evite dependências externas de tempo de execução.
• Recorte gráficos, capturas de tela, marcas repetidas e formas de onda em suas regiões de propriedade.
• Preserve uma capa existente e crie um irmão versionado, a menos que a substituição seja explicitamente solicitada.

4. Renderizar e validar mecanicamente

Renderize com o script fornecido quando o Sharp estiver disponível:

node <skill-directory>/scripts/render_svg.mjs <source.svg> <output.png>

Use --force apenas quando substituir a saída nomeada estiver no escopo. No Codex Desktop, carregue as dependências do espaço de trabalho e use o executável Node e o caminho do pacote retornados através de NODE_PATH; não instale uma dependência sem permissão.

Valide o PNG e o SVG:

python <skill-directory>/scripts/validate_preview.py <output.png> --svg <source.svg>

Crie a folha de miniaturas padrão:

node <skill-directory>/scripts/create_review_sheet.mjs <preview.png> <review.png>

Em páginas de código legadas do Windows, defina PYTHONUTF8=1 para ferramentas que leem código-fonte UTF-8.

5. Validar visualmente

Inspecione o raster em tamanho real e inspecione a folha de revisão gerada. Confirme:

• nome do repositório e declaração de valor permanecem legíveis em 320×160;
• a prova do produto é reconhecível e tecnicamente fiel;
• texto, marcas, recortes, painéis e elementos decorativos não colidem ou cortam;
• a composição funciona em fundos claro e escuro;
• cada elemento visível mapeia para a promessa ou prova;
• o design passa por todos os vetos específicos da rota aplicáveis.

Varra da esquerda para a direita e de cima para baixo, corrija um defeito nomeado de cada vez, renderize novamente e execute novamente a validação. Não entregue um defeito conhecido.

Para lotes, crie uma folha de contato e inspecione em busca de desvio acidental de modelo compartilhado antes de promover candidatos.

6. Fazer upload apenas quando solicitado

Criar um ativo não autoriza alterar as configurações do GitHub. Quando o upload for explicitamente solicitado, abra:

https://github.com/<owner>/<repo>/settings

Use Social preview → Edit → Upload an image… e siga a política de confirmação ativa da interface do usuário. Após o upload, busque a página pública do repositório e verifique se og:image resolve para a nova imagem 1280×640. Não relate sucesso a partir da miniatura de configurações sozinha.

Entrega

Mostre a imagem final e relate:

• caminho da fonte editável;
• caminho do raster, formato, dimensões e tamanho em bytes;
• justificativa de design em uma frase;
• status de validação e promoção de versão;
• status de upload: não solicitado, pendente ou verificado publicamente.

Não deixe a saída vinculada ao projeto apenas em um diretório temporário ou de propriedade do modelo.