repo-setup
$
npx mdskill add 686f6c61/alfred-dev/repo-setupAutomatiza configuración profesional de repositorios GitHub.
- Instala herramientas CLI y configura protecciones de ramas.
- Depende del cliente GitHub CLI para ejecutar comandos.
- Verifica prerrequisitos antes de proceder con la instalación.
- Ejecuta comandos de configuración directamente en la terminal.
SKILL.md
.github/skills/repo-setupView on GitHub ↗
--- name: repo-setup description: "Configurar un repositorio GitHub con branch protection, templates y labels" disable-model-invocation: true --- # Configurar repositorio GitHub ## Resumen Este skill configura un repositorio GitHub desde cero o ajusta uno existente para que cumpla con las convenciones de un proyecto profesional. Cubre protección de ramas, plantillas de issues y PR, etiquetas estandarizadas, .gitignore y metadatos del repositorio. La configuración se realiza íntegramente mediante la CLI `gh`, lo que permite automatizar y reproducir el proceso en cualquier proyecto sin depender de la interfaz web. ## Proceso 1. **Verificar prerrequisitos.** Comprobar que `gh` está instalada y autenticada. Si no lo está, preguntar al usuario si quiere que Alfred la instale. Si acepta, instalarla según la plataforma (`brew install gh` en macOS, `sudo apt install gh` en Linux, `winget install GitHub.cli` en Windows) y lanzar la autenticación con `gh auth login`. Sin esta herramienta no se puede continuar. 2. **Crear el repositorio o verificar el existente.** Si el repositorio no existe, crearlo con `gh repo create`. Si ya existe, verificar que se tiene acceso de administración para poder configurar las protecciones de rama. Establecer la descripción del repositorio y los topics relevantes con `gh repo edit`. 3. **Configurar branch protection en main.** Aplicar las siguientes reglas sobre la rama principal: - Requerir pull request antes de hacer merge. - Requerir al menos una aprobación. - Requerir que los checks de estado pasen antes de hacer merge. - No permitir force push. - No permitir borrado de la rama. Usar `gh api` para configurar las reglas de protección, ya que `gh` no tiene un comando directo para todas las opciones. 4. **Crear templates de issues.** Generar dos plantillas en `.github/ISSUE_TEMPLATE/`: - **bug_report.yml**: título, descripción del bug, pasos para reproducir, resultado esperado, resultado actual y entorno (SO, navegador, versión). - **feature_request.yml**: título, descripción del problema que se quiere resolver, solución propuesta y alternativas consideradas. 5. **Crear template de PR.** Generar `.github/pull_request_template.md` con secciones: resumen de cambios, motivación, plan de pruebas y checklist (tests, documentación, changelog). 6. **Configurar labels estándar.** Crear las siguientes etiquetas con `gh label create`: - Tipo: `bug`, `feature`, `docs`, `refactor`, `security`, `chore`. - Prioridad: `priority/critical`, `priority/high`, `priority/medium`, `priority/low`. - Estado: `needs-review`, `in-progress`, `blocked`. Eliminar las etiquetas por defecto que no se usen para evitar ruido. 7. **Generar .gitignore.** Crear o actualizar el fichero `.gitignore` según el stack del proyecto. Incluir siempre: `.env`, `.env.*`, `node_modules/`, `__pycache__/`, `.DS_Store`, `*.log`, ficheros de IDE (`.idea/`, `.vscode/`). 8. **Verificar la configuración.** Comprobar que las reglas de protección están activas, que los templates se renderizan correctamente al crear un issue o PR nuevo, y que las etiquetas son visibles. ## Que NO hacer - No mencionar herramientas de IA ni asistentes en ninguno de los artefactos generados (templates, descripción, etc.). - No configurar reglas de protección que bloqueen al usuario sin posibilidad de override en repositorios personales. - No asumir que `gh` está instalada: verificar siempre primero. - No borrar etiquetas existentes sin confirmar con el usuario.
More from 686f6c61/alfred-dev
- acceptance-criteriaGenerar criterios de aceptación en formato Given/When/Then. Activar cuando el usuario quiera definir criterios de aceptacion, usar formato Given When Then, escribir en Gherkin, saber como determinar que algo esta terminado o establecer una definicion de hecho.
- architecture-docsUsar para documentar la arquitectura del sistema. Activar ante: documentar arquitectura, diagrama del sistema, como funciona el proyecto, vision general tecnica
- bundle-sizeAnalizar y reducir el tamaño de bundles frontend. Activar cuando el bundle sea grande, se quiera reducir tamaño, aplicar tree shaking, configurar lazy loading, usar webpack analyzer o analizar el peso de la aplicacion.
- choose-stackUsar para evaluar y elegir tecnologías con matriz de decisión ponderada. Activar cuando el usuario quiera elegir tecnología, comparar frameworks, decidir entre alternativas técnicas, construir una matriz de decisión, evaluar stack, seleccionar base de datos, elegir lenguaje o comparar herramientas.
- ci-cd-pipelineConfigurar pipeline CI/CD adaptado al proyecto. Activar cuando el usuario quiera configurar CI, crear GitHub Actions, configurar GitLab CI, montar un pipeline de despliegue, automatizar tests o implementar integracion continua.
- code-review-responseUsar al recibir feedback de code review para responder técnicamente. Activar cuando el usuario quiera responder a comentarios de PR, gestionar feedback de code review, resolver comentarios de un revisor, o cuando el revisor pide cambios en el código.
- compliance-checkUsar para verificar cumplimiento RGPD, NIS2 y CRA. También: verificar RGPD, cumplimiento normativo, NIS2, CRA, Cyber Resilience Act, protección de datos, regulación europea.
- copy-reviewRevisar textos publicos: claridad, tono, ortografia y CTAs. Activar ante: revisar textos, mejorar copy, tono de comunicacion, textos de la web, landing page copy
- dependency-strategyEstrategia integral de gestion de dependencias: inventario, evaluacion de riesgo, politica de actualizaciones y documentacion. Usar para auditar el estado global de las dependencias del proyecto.
- dependency-updateRevisar dependencias desactualizadas, con CVEs o end-of-life, y proponer actualizaciones seguras. También: actualizar paquetes, actualizar dependencias, Dependabot, Renovate, versión desactualizada, breaking changes.