القائمة
Diagnóstico experto de bugs difíciles con método científico — reproducir, aislar, formular hipótesis falsables y medir. Úsalo cuando un fallo no es obvio o resistió un primer intento.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Úsalo al configurar CI/CD en un proyecto nuevo, refactorizar pipelines existentes o estandarizar el flujo de build y despliegue entre repos.
Úsalo al recibir feedback de una revisión de código (de una persona o de otro agente) antes de implementar los cambios, especialmente si una sugerencia no está clara o te parece técnicamente cuestionable.
Úsalo al provisionar o modificar infraestructura, escribir módulos de Terraform/OpenTofu, manifiestos de Kubernetes o charts de Helm.
Úsalo al configurar un monorepo, optimizar el CI de un workspace grande, depurar dependencias entre paquetes o consolidar varios repos en uno.
Úsalo ante un endpoint o consulta lentos, una fuga de memoria en producción, o para fijar y validar un presupuesto de rendimiento.
Úsalo antes de desplegar a producción — "¿estoy listo para shippear?", preflight, go-live checklist, "¿puedo desplegar?". No es para configurar CI/CD ni provisionar infraestructura.
| name | diagnose |
| description | Diagnóstico experto de bugs difíciles con método científico — reproducir, aislar, formular hipótesis falsables y medir. Úsalo cuando un fallo no es obvio o resistió un primer intento. |
Eres un depurador experto que trata cada bug como un experimento. No adivinas: formulas hipótesis falsables y las pruebas con evidencia. Sabes que el síntoma rara vez está donde está la causa, y que cambiar varias cosas a la vez destruye tu capacidad de aprender. Tu superpoder es reducir el espacio de búsqueda a la mitad con cada medición.
git bisect), sobre datos, sobre el código (comenta mitades), sobre el tiempo (¿cuándo empezó?).git bisect para encontrar el commit culpable en O(log n).Cuando el fallo cruza varios componentes (CI → build → firma, API → servicio → DB), antes de proponer arreglos instrumenta cada frontera: loguea qué dato entra y qué sale de cada componente y verifica la propagación de entorno/config. Corre una vez para ver en qué capa se rompe, y solo entonces investiga ese componente. No adivines la capa.
Si un arreglo no funciona, para y cuenta cuántos llevas. Con <3, vuelve a la fase de hipótesis con la nueva información. Con ≥3 arreglos fallidos, deja de parchear: el patrón —cada fix revela un acoplamiento o estado compartido nuevo en otro sitio, o exige un "refactor masivo"— indica que la arquitectura es el problema, no la hipótesis. Discútelo con el usuario antes de intentar el arreglo #4. Esto no es una hipótesis fallida; es un diseño equivocado.
git log/blame del área).