菜单
Bucle de diagnóstico para bugs difíciles y regresiones de rendimiento. Usar cuando el usuario diga "diagnostica"/"debuggea esto", o reporte algo roto, que lanza errores, que falla o que va lento.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/KroxiDev/claude-dev-skills --skill diagnosing-bugs命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Modo de respuesta ultracomprimida — habla como un cavernícola inteligente. Niveles lite (por defecto), full y ultra.
Una entrevista sin descanso que hace todas las preguntas del frontier a la vez, ronda a ronda.
Traspasa la tarea actual a otra sesión del mismo workspace — un prompt copiable por defecto, o un documento markdown si lo pides.
基于 SOC 职业分类
正在显示 SKILL.md
| name | diagnosing-bugs |
| description | Bucle de diagnóstico para bugs difíciles y regresiones de rendimiento. Usar cuando el usuario diga "diagnostica"/"debuggea esto", o reporte algo roto, que lanza errores, que falla o que va lento. |
Una disciplina para bugs difíciles. Saltarse fases solo cuando esté explícitamente justificado.
Al explorar el codebase, leer CONTEXT.md (si existe) para obtener un modelo mental claro de los módulos relevantes, y revisar los ADRs del área que se está tocando.
Esto es el skill. Todo lo demás es mecánico. Si tienes una señal pass/fail ajustada para el bug — una que se ponga red con este bug — encontrarás la causa; la bisección, la prueba de hipótesis y la instrumentación no hacen más que consumirla. Si no la tienes, ninguna cantidad de mirar código te salvará.
Dedica aquí un esfuerzo desproporcionado. Sé agresivo. Sé creativo. Niégate a rendirte.
git bisect run.Construye el bucle de feedback correcto y el bug está resuelto al 90%.
Trata el bucle como un producto. En cuanto tengas un bucle, ajústalo:
Un bucle flaky de 30 segundos es apenas mejor que ningún bucle; uno determinista de 2 segundos es ajustado — un superpoder de debugging.
El objetivo no es una repro limpia sino una tasa de reproducción más alta. Ejecuta el trigger en bucle 100×, paraleliza, añade estrés, estrecha ventanas de timing, inyecta sleeps. Un bug que falla el 50% de las veces es debuggeable; el 1% no — sigue subiendo la tasa hasta que sea debuggeable.
Detente y dilo explícitamente. Lista lo que intentaste. Pide al usuario: (a) acceso al entorno que lo reproduce, (b) un artefacto capturado (archivo HAR, volcado de logs, core dump, grabación de pantalla con timestamps), o (c) permiso para añadir instrumentación temporal en producción. No procedas a hipotetizar sin un bucle.
La Fase 1 está lista cuando el bucle es ajustado y capaz de ponerse red: puedes nombrar un comando — la ruta de un script, la invocación de un test, un curl — que ya has ejecutado al menos una vez (pega la invocación y su salida), y que es:
Si te sorprendes leyendo código para armar una teoría antes de que este comando exista, para — saltar directo a una hipótesis es exactamente el fallo que este skill previene. Sin comando capaz de ponerse red, no hay Fase 2.
Ejecuta el bucle. Míralo ponerse red — el bug aparece.
Confirma:
En cuanto esté red, encoge la repro al escenario más pequeño que siga poniéndose red. Recorta entradas, callers, configuración, datos y pasos de uno en uno, re-ejecutando el bucle tras cada recorte — conserva solo lo que sostiene el fallo.
Por qué molestarse: una repro mínima encoge el espacio de hipótesis de la Fase 3 (quedan menos piezas móviles que sospechar) y se convierte en el test de regresión limpio de la Fase 5.
Está listo cuando cada elemento restante sostiene el fallo — quitar cualquiera de ellos hace que el bucle se ponga green.
No avances hasta haber reproducido y minimizado.
Genera 3–5 hipótesis rankeadas antes de probar ninguna. Generar una sola hipótesis ancla en la primera idea plausible.
Cada hipótesis debe ser falsable: enuncia la predicción que hace.
Formato: "Si es la causa, entonces hará desaparecer el bug / lo empeorará."
Si no puedes enunciar la predicción, la hipótesis es una corazonada — descártala o afílala.
Muestra la lista rankeada al usuario antes de probar. A menudo tiene conocimiento de dominio que re-rankea al instante ("acabamos de desplegar un cambio en la #3"), o conoce hipótesis que ya descartó. Checkpoint barato, gran ahorro de tiempo. No te bloquees en él — continúa con tu ranking si el usuario está ausente.
Cada sonda debe mapear a una predicción específica de la Fase 3. Cambia una variable por vez.
Preferencia de herramientas:
Etiqueta cada log de debug con un prefijo único, p. ej. [DEBUG-a4f2]. La limpieza final se vuelve un solo grep. Los logs sin etiqueta sobreviven; los etiquetados mueren.
Rama de rendimiento. Para regresiones de rendimiento, los logs suelen ser la herramienta equivocada. En su lugar: establece una medición de línea base (harness de timing, performance.now(), profiler, query plan) y luego bisecta. Medir primero, arreglar después.
Escribe el test de regresión antes del fix — pero solo si existe un seam correcto para él.
Un seam correcto es uno donde el test ejercita el patrón real del bug tal como ocurre en el call site. Si el único seam disponible es demasiado superficial (test de un solo caller cuando el bug necesita varios, unit test que no puede replicar la cadena que disparó el bug), un test de regresión ahí da falsa confianza.
Si no existe un seam correcto, eso mismo es el hallazgo. Anótalo. La arquitectura del codebase está impidiendo dejar el bug bajo llave. Márcalo para la fase siguiente.
Si existe un seam correcto:
Requerido antes de declarar terminado:
[DEBUG-...] eliminada (grep del prefijo)Después pregunta: ¿qué habría prevenido este bug? Si la respuesta implica cambio arquitectónico (sin buen seam de test, callers enredados, acoplamiento oculto), traspásalo al skill /improve-codebase-architecture con los detalles. Haz la recomendación después de que el fix esté dentro, no antes — ahora tienes más información que cuando empezaste.