The whole file
This is exactly what you download: no summaries, nothing trimmed.
Heads-up: the skill file itself is written in Spanish. Agents read it fine and answer in your language, but the prose below is not translated.
Azure Repos: auditar varios repositorios
Auditar no es leer todo el código. Es responder, con datos, a dónde duele y qué se hace primero.
1. Inventario
az repos list --output json \
--query "[].{name:name, size:size, defaultBranch:defaultBranch, disabled:isDisabled}"
Clona en superficie lo que vayas a analizar; el historial completo de veinte repos es media hora tirada:
git clone --filter=blob:none --depth 200 <url> repos/<nombre>
2. Señales, en orden de rentabilidad
Actividad — qué está vivo. Primera criba, y la más barata:
git log -1 --format=%cd --date=short # último commit
git shortlog -sne --since="12 months ago" # quién lo mantiene
Un repo sin commits en 12 meses y con dependencias antiguas no es “estable”: es un repo que nadie sabe desplegar. Un repo con un solo autor es un riesgo de continuidad, aunque el código sea impecable.
Dependencias — el riesgo que entra sin que lo escribas.
dotnet list package --vulnerable --include-transitive
dotnet list package --outdated
npm audit --omit=dev
Prioriza por severidad y por exposición: un CVE crítico en una utilidad interna sin entrada de red va después de uno medio en el servicio público. Anota también las dependencias sin mantenimiento (último release > 2 años) y las duplicadas: tres librerías de logging distintas en cinco repos son coste permanente.
Puntos calientes — dónde se rompe. El cruce de “se cambia mucho” con “es complejo” acierta mucho más que cualquier métrica sola:
git log --since="12 months ago" --name-only --format= | sort | uniq -c | sort -rn | head -30
Un fichero de 900 líneas que nadie toca puede esperar. Uno de 300 que se toca cada semana y concentra los bugs es donde va el esfuerzo.
Convenciones — divergencia entre repos. Presencia de .editorconfig,
versión de TFM (net6.0 conviviendo con net8.0), analizadores activados,
TreatWarningsAsErrors, tests que existan y se ejecuten en el pipeline.
La divergencia se paga cada vez que alguien cambia de repo.
Secretos en el historial. Búsqueda de cadenas de conexión, AccountKey=,
tokens y ficheros .pfx/.pem versionados. Un hallazgo aquí sube al primer
puesto del informe: si está en el historial, rotarlo es lo urgente; borrarlo
del repo viene después.
3. El informe
Una tabla de una línea por repo, y debajo lo accionable:
REPO ACTIVIDAD TFM VULNS TESTS RIESGO
api-pedidos activo net8.0 0 sí bajo
portal-cliente activo net6.0 2 altas sí alto
integraciones-legacy 14 meses net48 5 (1 crít) no crítico
utilidades-comunes activo net8.0 0 no medio
Después, máximo cinco acciones, cada una con coste estimado y qué evita:
1. Rotar la cadena de conexión de integraciones-legacy (está en el
historial desde 2022). 1 h · crítico
2. Subir portal-cliente a net8.0 (net6.0 sin soporte). 2 d · alto
3. Cubrir con tests el módulo de facturación de utilidades-
comunes: 4 de los 7 bugs del último trimestre salieron de
ahí. 3 d · medio
Reglas
- Datos, no impresiones. Cada afirmación del informe apunta a un comando, una ruta o un número reproducible.
- Nada de “hay que refactorizar”. Refactorizar qué, cuánto cuesta y qué bug concreto deja de repetirse.
- Cinco acciones. Una lista de treinta mejoras no se ejecuta nunca y hace que la próxima auditoría no se lea.
- La auditoría no modifica nada. Ni formatea, ni actualiza paquetes, ni abre PRs por su cuenta.