onovich/RepoCover

¿Qué hace RepoCover?

Crea una previsualización social específica del repositorio que se mantiene legible en tamaño miniatura. Prefiere una composición determinista y editable sobre un banner genérico generado.

Invariantes del producto

• Entregar un ráster exacto de 1280×640, normalmente PNG, con un tamaño inferior a 1.000.000 bytes.
• Mantener una fuente editable, normalmente SVG, junto al ráster.
• Fundamentar las afirmaciones, métricas, capturas de pantalla y pruebas visibles en la evidencia del repositorio.
• Preservar la identidad del repositorio en lugar de imponer un estilo único.
• Validar el tamaño completo y 320×160 en fondos claros y oscuros.
• Tratar la creación de imágenes y la subida a GitHub como límites de autorización separados.
• No implicar afiliación o respaldo de GitHub.

Cargar las referencias correctas

Lee estos dos archivos para cada portada:

• references/common-quality.md para las puertas de composición y rechazo universales.
• references/design-ledger-template.md para el registro de evidencia, diseño y validación.

Luego lee solo la ruta que corresponda:

• Lee references/source-material.md cuando existan capturas de pantalla, capturas de ejecución, logotipos, ilustraciones, SVG, sprites, texturas u otros elementos visuales significativos.
• Lee references/cold-start.md cuando no exista una captura de pantalla utilizable, captura de ejecución, marca comercial o elemento visual principal perteneciente al repositorio.
• Lee references/version-regression.md al actualizar una portada existente, comparar candidatos o generar un lote versionado.

No cargues una ruta irrelevante solo porque exista. references/design-recipes.md es solo un índice de compatibilidad para prompts antiguos.

Flujo de trabajo

1. Inspeccionar y acotar la evidencia

Lee los archivos AGENTS.md correspondientes, el README, los metadatos del paquete, las rutas de código fuente significativas, los activos visuales y cualquier previsualización social existente. Identifica:

• nombre del repositorio y tarea principal del usuario;
• una declaración de valor concreta;
• como máximo tres puntos de prueba;
• la evidencia de producto más sólida;
• identidad visual establecida y hechos secundarios a excluir;
• modo de evidencia: remote-static, local-static, build-tested o runtime-tested.

Nunca implies que se ejecutó una compilación, ejecución, escena o prueba cuando solo se inspeccionó evidencia estática. Si los requisitos de imagen de GitHub pudieran haber cambiado, verifícalos contra la documentación oficial de GitHub.

Para un repositorio remoto, utiliza la evidencia disponible de GitHub (pública o autenticada) para inspeccionar su README, árbol, manifiestos, archivos fuente significativos, previsualización actual y los activos visuales más sólidos. Mantén los resultados en un directorio duradero visible para el usuario y registra las URL de origen y los límites de las afirmaciones. Si no se puede acceder a ninguna ejecución o interfaz representativa, indica esa limitación en lugar de pretender que la evidencia remota equivale a una previsualización local funcional. Los proyectos locales previsualizables, especialmente proyectos web con una interfaz existente, suelen proporcionar la evidencia visual más rica.

2. Escribir el registro y elegir la ruta

Crea un registro de diseño a partir de la plantilla incluida antes de dibujar. Como mínimo, registra:

• Promesa, prueba, excluir;
• modo de evidencia y límites de las afirmaciones;
• diagnóstico de material fuente o esqueleto semántico de arranque en frío;
• ruta de producción e interpretación elegida;
• decisiones de material, rol de activo, topología y línea;
• veredicto de versión de salida, validación y promoción, cuando corresponda.

Elige la ruta de producción más pequeña que preserve la identidad:

• SVG nativo del código — preferido: herramientas para desarrolladores, diagramas, gráficos, logotipos, bibliotecas y sistemas visuales inferidos.
• Híbrido de captura de pantalla o fuente: solo cuando un artefacto fuente autocontenido siga siendo la prueba más clara después del diagnóstico.
• Híbrido de ilustración: solo cuando la ilustración sea central para la identidad del repositorio; genera la obra de arte sin texto importante y superpone el texto exacto en SVG.

No invoques la generación de imágenes solo para imitar un sistema vectorial establecido.

3. Construir y versionar la fuente editable

Por defecto, usa docs/social-preview.svg y docs/social-preview.png a menos que el repositorio tenga una convención de activos clara o el usuario nombre otro destino.

• Usa un viewBox de 1280 640 y un fondo de lienzo completo.
• Mantén el contenido esencial dentro de un área segura exterior de aproximadamente 72 píxeles.
• Divide el texto, la prueba del producto, los pies de foto y la firma en regiones que no se superpongan.
• Usa fuentes del sistema a menos que el repositorio incluya una fuente con licencia adecuada.
• Inserta la evidencia local o reprodúcela con primitivas SVG deterministas; evita dependencias externas de ejecución.
• Recorta gráficos, capturas de pantalla, marcas repetidas y formas de onda dentro de sus regiones propietarias.
• Conserva una portada existente y crea una versión hermanada a menos que se solicite explícitamente el reemplazo.

4. Renderizar y validar mecánicamente

Renderiza con el script incluido cuando Sharp esté disponible:

node <directorio-de-la-skill>/scripts/render_svg.mjs <source.svg> <output.png>

Usa --force solo cuando reemplazar la salida nombrada esté dentro del alcance. En Codex Desktop, carga las dependencias del espacio de trabajo y usa el ejecutable de Node y la ruta del paquete devueltos a través de NODE_PATH; no instales una dependencia sin permiso.

Valida el PNG y el SVG:

python <directorio-de-la-skill>/scripts/validate_preview.py <output.png> --svg <source.svg>

Crea la hoja de miniaturas estándar:

node <directorio-de-la-skill>/scripts/create_review_sheet.mjs <preview.png> <review.png>

En páginas de códigos heredadas de Windows, establece PYTHONUTF8=1 para herramientas que lean fuentes UTF-8.

5. Validar visualmente

Inspecciona el ráster a tamaño completo e inspecciona la hoja de revisión generada. Confirma:

• el nombre del repositorio y la declaración de valor siguen siendo legibles a 320×160;
• la prueba del producto es reconocible y técnicamente fiel;
• el texto, las marcas, los recortes, los paneles y los elementos decorativos no chocan ni se recortan;
• la composición funciona en fondos claros y oscuros;
• cada elemento visible se corresponde con la promesa o la prueba;
• el diseño supera todos los vetos aplicables específicos de la ruta.

Escanea de izquierda a derecha y de arriba a abajo, corrige un defecto nombrado a la vez, vuelve a renderizar y vuelve a ejecutar la validación. No entregues un defecto conocido.

Para lotes, crea una hoja de contactos e inspecciona en busca de desviaciones accidentales de plantilla compartida antes de promover candidatos.

6. Subir solo cuando se solicite

Crear un activo no autoriza a cambiar la configuración de GitHub. Cuando se solicite explícitamente la subida, abre:

https://github.com/<propietario>/<repositorio>/settings

Usa Previsualización social → Editar → Subir una imagen… y sigue la política de confirmación activa de la interfaz de usuario. Después de la subida, obtén la página pública del repositorio y verifica que og:image se resuelva a la nueva imagen de 1280×640. No informes del éxito solo desde la miniatura de configuración.

Entrega

Muestra la imagen final e informa:

• ruta de la fuente editable;
• ruta, formato, dimensiones y tamaño en bytes del ráster;
• justificación del diseño en una frase;
• estado de validación y promoción de versión;
• estado de subida: no solicitado, pendiente o verificado públicamente.

No dejes resultados específicos del proyecto solo en un directorio temporal o propiedad del modelo.