メニュー
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コマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？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.