italixcs/limpiador-repo

Limpiador de Repositorios

Haz que el propósito, la evidencia y la primera acción útil de un buen proyecto sean fáciles de encontrar. Mejora la superficie del repositorio mientras se preserva el comportamiento de la aplicación.

1. Establecer el resumen

• Identificar el repositorio, la audiencia, el resultado deseado, el idioma, y si es auditoría o implementación. Reutilizar la autorización ya otorgada.
• Leer las instrucciones aplicables, el README, guías enlazadas, licencia, manifiestos de paquetes/habilidades, ejemplos, activos y metadatos actuales de GitHub. Inspeccionar el código fuente solo cuando sea necesario para verificar afirmaciones y comandos.
• Inspeccionar el árbol de trabajo y preservar los cambios no relacionados, la licencia existente y la atribución. Mantener la visibilidad sin cambios a menos que se autorice explícitamente un cambio de visibilidad.
• Hacer preguntas enfocadas sobre hechos faltantes o decisiones importantes: audiencia, marca conflictiva, acceso no disponible, instalación incierta o un cambio de marca significativo. Resolver las decisiones de diseño rutinarias basándose en el proyecto. Continuar el trabajo independiente mientras se espera; no inventar hechos para evitar preguntar.
• Usar assets/repo-brief.md si un resumen de trabajo ayuda; no agregarlo a cada repositorio objetivo.

2. Auditar el camino del lector

Leer references/audit-and-validation.md. Seguir el camino: descubrimiento → primera pantalla → evidencia → instalación → primer éxito → ayuda más profunda.

Enumere las pocas brechas de mayor impacto con evidencia y prioridad. Separar los problemas fácticos de las elecciones de gusto. Incluir el desorden a eliminar. Distinguir la información faltante de la información no disponible para sus herramientas. Para trabajo solo de auditoría, devolver hallazgos y recomendaciones concretas sin editar archivos o configuraciones.

3. Construir una presentación coherente

Leer references/readme-and-visuals.md. Por defecto, usar el estilo de documento nativo de GitHub, insignias planas estándar, enlaces de navegación comunes y evidencia específica del proyecto. No reutilizar la estética del perfil personal de un autor a menos que se solicite. Leer references/readme-patterns.md al elegir una estructura o aprender de repositorios de referencia. Elegir una dirección adecuada para el proyecto, luego implementar el conjunto más pequeño completo de activos y documentos que lo hagan comprensible y utilizable.

• Comenzar con una promesa específica, evidencia visual útil y una primera acción clara. Mantener la información esencial como texto real.
• Agregar un banner solo cuando sea útil; preferir una tarea concreta, un resultado real o un showcase útil sobre una marca decorativa; capturar capturas de pantalla de resultados reales. Etiquetar conceptos, instalaciones, reconstrucciones y vistas previas locales con precisión.
• Agregar una fila de insignias restringida con destinos funcionales y afirmaciones respaldadas.
• Mantener el ejemplo de instalación y uso más corto verificado en el README. Enlazar guías de plataforma más largas, solución de problemas y ejemplos sin duplicarlos.
• Organizar documentos públicos y activos sin mover el código fuente de la aplicación ni cambiar el comportamiento de tiempo de ejecución/compilación. Actualizar enlaces al mover documentación.
• Ajustar la profundidad de la documentación al proyecto. Eliminar copias de marketing genéricas, lemas repetidos, tablas de funciones forzadas, secciones de relleno, muros de insignias, diagramas decorativos y jerarquías de carpetas vacías. Mantener la voz específica del proyecto.

Para repositorios de habilidades, verificar que la carpeta instalable incluya SKILL.md y todos los recursos referenciados. Separar ese paquete de los documentos de marketing públicos. Documentar las rutas exactas de descubrimiento por host, ejemplos de invocación, requisitos previos y requisitos de herramientas. Indicar si cada ruta fue probada en tiempo de ejecución, verificada contra la documentación del host, o solo utilizable manualmente. No inferir un plugin, listado en marketplace o soporte universal de agente a partir de una carpeta de habilidad simple.

4. Mejorar el descubrimiento con metadatos veraces

Leer references/github-discovery.md. Proponer un texto Acerca de conciso, una página de inicio real útil cuando esté disponible, temas respaldados por evidencia y un activo de vista previa social. Verificar los límites actuales de GitHub antes de aplicarlos.

Aplicar configuraciones autorizadas con herramientas adecuadas, preservando los valores existentes relevantes. Si las herramientas carecen de una operación, preparar los valores exactos y el enlace de configuración. Separar lo aplicado, lo preparado y lo bloqueado. Un archivo de metadatos comprometido o una imagen social no configuran GitHub. Nunca cambiar la visibilidad, contactar a otros o enviar listados promocionales sin autorización.

5. Verificar y entregar

Validar la ruta del lector con la referencia de auditoría: enlaces y anclajes, imágenes, inicio rápido seguro, insignias y compatibilidad veraces, escritorio/móvil, claro/oscuro, diff final y lectura de configuración. Reportar limitaciones de herramientas o red explícitamente. Guardar los activos fuente para que las actualizaciones posteriores sigan siendo prácticas.

Hacer commit o push solo cuando esté autorizado y seguir el flujo de trabajo del repositorio objetivo. Confirmar el destino y la revisión final. Resumir los cambios, la verificación, las configuraciones no aplicadas y las pocas acciones restantes. No prometer tráfico, estrellas, ranking o soporte no probado.