/sonarqube
Levantar SonarQube con Docker, analizar el código y proponer mejoras. También: análisis estático, deuda técnica, code smells, cobertura, calidad automatizada.
$ npx -y skills add 686f6c61/alfred-dev --skill sonarqube --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/sonarqube
Context preview
The summary Claude sees to decide when to auto-load this skill.
Levantar SonarQube con Docker, analizar el código y proponer mejoras. También: análisis estático, deuda técnica, code smells, cobertura, calidad automatizada.
SKILL.md
sonarqube.SKILL.mdname: sonarqube
description: "Levantar SonarQube con Docker, analizar el código y proponer mejoras. También: análisis estático, deuda técnica, code smells, cobertura, calidad automatizada."
disable-model-invocation: true
Análisis de calidad con SonarQube
Resumen
Este skill levanta una instancia de SonarQube con Docker, ejecuta un análisis del código del proyecto y traduce los resultados en propuestas de mejora accionables. SonarQube detecta bugs, vulnerabilidades, code smells y problemas de cobertura que las herramientas de linting no cubren.
No sustituye al qa-engineer ni al security-officer: complementa su trabajo con una segunda opinión automatizada basada en reglas estáticas probadas en millones de proyectos.
Proceso
Paso 1: preflight de Docker y permisos
Comprobar si Docker está disponible y si el daemon responde:
docker --version
docker info
Interpreta el resultado con estas reglas:
- **Si `docker --version` falla**: Docker no está instalado. Explica al usuario que SonarQube lo necesita y que la instalación puede requerir permisos de administrador.
- **Si `docker --version` funciona pero `docker info` falla**: Docker está instalado, pero el daemon no está disponible. Explica al usuario que hay que arrancar Docker Desktop o el servicio del sistema antes de continuar.
**No instales Docker, no abras Docker Desktop y no arranques el daemon sin aprobación explícita del usuario.** Si la orden viene desde `/alfred audit`, respeta la decisión tomada en su preflight. Si no existe una autorización previa, pídela ahora y espera respuesta.
Si el usuario autoriza la instalación, instala la última versión estable según la plataforma:
**macOS:**
brew install --cask docker
open -a Docker
**Linux (Ubuntu/Debian):**
curl -fsSL https://get.docker.com | sh
sudo systemctl start docker
sudo usermod -aG docker $USER
**Windows (PowerShell como administrador):**
winget install Docker.DockerDesktop
Si el usuario autoriza arrancar Docker cuando está instalado pero el daemon no responde, usa la estrategia mínima necesaria para la plataforma:
**macOS:**
open -a Docker
**Linux (systemd):**
sudo systemctl start docker
**Windows (PowerShell):**
Start-Process "C:\Program Files\Docker\Docker\Docker Desktop.exe"
Después de instalar o arrancar Docker, verifica otra vez con `docker info`.
- Si `docker info` responde correctamente, continúa.
- Si el usuario rechaza la instalación o el arranque, o si el daemon sigue sin responder, **detén aquí la rama de SonarQube** y devuelve un resultado explícito: "SonarQube omitido por decisión del usuario o por falta de permisos". No intentes forzarlo por otras vías.
Paso 2: levantar SonarQube
Antes de levantar el contenedor:
- Comprueba si ya existe `sonarqube-alfred`. Si existe de una ejecución anterior, elimínalo primero para evitar conflictos:
docker rm -f sonarqube-alfred 2>/dev/null || true
- Comprueba si el puerto `9000` ya está en uso. Si lo está, detén la ejecución y pregunta al usuario si quiere liberar ese puerto o continuar sin SonarQube. No mates procesos por tu cuenta.
docker run -d --name sonarqube-alfred -p 9000:9000 sonarqube:community
Esperar a que SonarQube esté listo (puede tardar 1-2 minutos):
Usa este bucle exacto o uno equivalente. **No uses la variable `status` en scripts de shell**: en `zsh` es de solo lectura y romperá la espera. Si necesitas guardar el estado en una variable, usa `sonar_status`.
until curl -s http://localhost:9000/api/system/status | grep -q '"status":"UP"'; do sleep 5; done
Credenciales por defecto: admin/admin. Cambiar la contraseña en el primer acceso.
Paso 3: configurar el proyecto
- Crear un proyecto en SonarQube (vía API o interfaz web).
- Generar un token de autenticación para el análisis.
- Crear o verificar el fichero `sonar-project.properties` en la raíz del proyecto:
sonar.projectKey=nombre-del-proyecto
sonar.sources=src
sonar.tests=tests
sonar.language=ts
sonar.sourceEncoding=UTF-8
Adaptar según el stack del proyecto (lenguaje, directorios de código y tests).
Paso 4: ejecutar el análisis
Para proyectos Node/TypeScript:
npx sonarqube-scanner
Para proyectos Python:
pip install pysonar-scanner && pysonar-scanner
Alternativa universal con Docker:
docker run --rm -v "$(pwd):/usr/src" sonarsource/sonar-scanner-cli
Paso 5: interpretar resultados
Acceder a http://localhost:9000 y revisar el dashboard del proyecto. Clasificar los hallazgos por:
- **Bugs**: errores que pueden causar comportamiento incorrecto. Prioridad alta.
- **Vulnerabilidades**: problemas de seguridad detectados por reglas OWASP/CWE. Notificar al security-officer.
- **Code smells**: problemas de mantenibilidad. Priorizar los de mayor impacto.
- **Cobertura**: porcentaje de código cubierto por tests. Identificar zonas sin cobertura críticas.
Paso 6: generar informe de mejoras
Crear un informe con:
- Resumen ejecutivo: métricas principales (bugs, vulnerabilidades, cobertura, deuda técnica).
- Top 10 hallazgos por impacto con la corrección propuesta.
- Zonas de código con mayor densidad de problemas.
- Comparación con el análisis anterior si existe.
Paso 7: limpiar
Cuando el análisis esté completo y los resultados revisados:
docker stop sonarqube-alfred && docker rm sonarqube-alfred
Si el análisis falla a mitad del proceso, intenta igualmente la limpieza final del contenedor temporal antes de salir.
Qué NO hacer
- No dejar SonarQube corriendo indefinidamente. Es una herramienta de análisis puntual, no un servicio permanente.
- No instalar Docker, arrancar el daemon ni abrir Docker Desktop sin permiso explícito del usuario.
- No tratar todos los hallazgos como iguales. Priorizar por impacto real, no por cantidad.
- No corregir hallazgos sin entender por qué SonarQube los marca.
Read more
name: sonarqube description: "Levantar SonarQube con Docker, analizar el código y proponer mejoras. También: análisis estático, deuda técnica, code smells, cobertura, calidad automatizada." disable-model-invocation: true
Análisis de calidad con SonarQube
Resumen
Este skill levanta una instancia de SonarQube con Docker, ejecuta un análisis del código del proyecto y traduce los resultados en propuestas de mejora accionables. SonarQube detecta bugs, vulnerabilidades, code smells y problemas de cobertura que las herramientas de linting no cubren.
No sustituye al qa-engineer ni al security-officer: complementa su trabajo con una segunda opinión automatizada basada en reglas estáticas probadas en millones de proyectos.
Proceso
Paso 1: preflight de Docker y permisos
Comprobar si Docker está disponible y si el daemon responde:
docker --version docker info
Interpreta el resultado con estas reglas:
- **Si `docker --version` falla**: Docker no está instalado. Explica al usuario que SonarQube lo necesita y que la instalación puede requerir permisos de administrador.
- **Si `docker --version` funciona pero `docker info` falla**: Docker está instalado, pero el daemon no está disponible. Explica al usuario que hay que arrancar Docker Desktop o el servicio del sistema antes de continuar.
**No instales Docker, no abras Docker Desktop y no arranques el daemon sin aprobación explícita del usuario.** Si la orden viene desde `/alfred audit`, respeta la decisión tomada en su preflight. Si no existe una autorización previa, pídela ahora y espera respuesta.
Si el usuario autoriza la instalación, instala la última versión estable según la plataforma:
**macOS:**
brew install --cask docker open -a Docker
**Linux (Ubuntu/Debian):**
curl -fsSL https://get.docker.com | sh sudo systemctl start docker sudo usermod -aG docker $USER
**Windows (PowerShell como administrador):**
winget install Docker.DockerDesktop
Si el usuario autoriza arrancar Docker cuando está instalado pero el daemon no responde, usa la estrategia mínima necesaria para la plataforma:
**macOS:**
open -a Docker
**Linux (systemd):**
sudo systemctl start docker
**Windows (PowerShell):**
Start-Process "C:\Program Files\Docker\Docker\Docker Desktop.exe"
Después de instalar o arrancar Docker, verifica otra vez con `docker info`.
- Si `docker info` responde correctamente, continúa.
- Si el usuario rechaza la instalación o el arranque, o si el daemon sigue sin responder, **detén aquí la rama de SonarQube** y devuelve un resultado explícito: "SonarQube omitido por decisión del usuario o por falta de permisos". No intentes forzarlo por otras vías.
Paso 2: levantar SonarQube
Antes de levantar el contenedor:
- Comprueba si ya existe `sonarqube-alfred`. Si existe de una ejecución anterior, elimínalo primero para evitar conflictos:
docker rm -f sonarqube-alfred 2>/dev/null || true
- Comprueba si el puerto `9000` ya está en uso. Si lo está, detén la ejecución y pregunta al usuario si quiere liberar ese puerto o continuar sin SonarQube. No mates procesos por tu cuenta.
docker run -d --name sonarqube-alfred -p 9000:9000 sonarqube:community
Esperar a que SonarQube esté listo (puede tardar 1-2 minutos):
Usa este bucle exacto o uno equivalente. **No uses la variable `status` en scripts de shell**: en `zsh` es de solo lectura y romperá la espera. Si necesitas guardar el estado en una variable, usa `sonar_status`.
until curl -s http://localhost:9000/api/system/status | grep -q '"status":"UP"'; do sleep 5; done
Credenciales por defecto: admin/admin. Cambiar la contraseña en el primer acceso.
Paso 3: configurar el proyecto
- Crear un proyecto en SonarQube (vía API o interfaz web).
- Generar un token de autenticación para el análisis.
- Crear o verificar el fichero `sonar-project.properties` en la raíz del proyecto:
sonar.projectKey=nombre-del-proyecto sonar.sources=src sonar.tests=tests sonar.language=ts sonar.sourceEncoding=UTF-8
Adaptar según el stack del proyecto (lenguaje, directorios de código y tests).
Paso 4: ejecutar el análisis
Para proyectos Node/TypeScript:
npx sonarqube-scanner
Para proyectos Python:
pip install pysonar-scanner && pysonar-scanner
Alternativa universal con Docker:
docker run --rm -v "$(pwd):/usr/src" sonarsource/sonar-scanner-cli
Paso 5: interpretar resultados
Acceder a http://localhost:9000 y revisar el dashboard del proyecto. Clasificar los hallazgos por:
- **Bugs**: errores que pueden causar comportamiento incorrecto. Prioridad alta.
- **Vulnerabilidades**: problemas de seguridad detectados por reglas OWASP/CWE. Notificar al security-officer.
- **Code smells**: problemas de mantenibilidad. Priorizar los de mayor impacto.
- **Cobertura**: porcentaje de código cubierto por tests. Identificar zonas sin cobertura críticas.
Paso 6: generar informe de mejoras
Crear un informe con:
- Resumen ejecutivo: métricas principales (bugs, vulnerabilidades, cobertura, deuda técnica).
- Top 10 hallazgos por impacto con la corrección propuesta.
- Zonas de código con mayor densidad de problemas.
- Comparación con el análisis anterior si existe.
Paso 7: limpiar
Cuando el análisis esté completo y los resultados revisados:
docker stop sonarqube-alfred && docker rm sonarqube-alfred
Si el análisis falla a mitad del proceso, intenta igualmente la limpieza final del contenedor temporal antes de salir.
Qué NO hacer
- No dejar SonarQube corriendo indefinidamente. Es una herramienta de análisis puntual, no un servicio permanente.
- No instalar Docker, arrancar el daemon ni abrir Docker Desktop sin permiso explícito del usuario.
- No tratar todos los hallazgos como iguales. Priorizar por impacto real, no por cantidad.
- No corregir hallazgos sin entender por qué SonarQube los marca.
Showing the first part of this file.
Plugin de Claude Code: 18 agentes especializados, 60 skills, 25 comandos, 13 hooks, memoria persistente, Memory UI local, quality gates, evidence guard, continuidad operativa y modo autopilot.
Repo: 686f6c61/alfred-dev
Other skills on alfred-dev.
- /alfred
Alias global /alfred para abrir el asistente contextual de Alfred Dev sin escribir el namespace completo. Activar solo cuando el usuario invoque explicitamente /alfred.
Open skill - /choose-stack
Usar 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
Open skill - /design-system
Usar para diseñar la arquitectura de un sistema con diagramas y contratos. Activar cuando el usuario quiera diseñar arquitectura, definir componentes del sistema, crear un diagrama de flujo, establecer contratos entre módulos, planificar la estructura del proyecto o decidir cómo
Open skill - /evaluate-dependencies
Usar para evaluar si una dependencia merece la pena antes de añadirla. Activar cuando el usuario quiera añadir una librería, saber si merece la pena esta dependencia, evaluar un paquete antes de instalarlo, hacer npm install o pip install de algo nuevo, buscar alternativas a una
Open skill - /write-adr
Usar para documentar decisiones arquitectónicas como ADR. Activar cuando el usuario quiera documentar por qué se tomó una decisión, registrar alternativas descartadas, crear un ADR, un decision record, dejar constancia de una elección técnica o justificar una decisión de diseño
Open skill - /code-review
Usar para revisar código con foco en calidad, legibilidad y errores lógicos. También: revisar código, buscar errores, calidad del código, revisión de PR, pull request review.
Open skill

