Awsaf780/claude-skills

Readback (Devolución de Lectura)

El problema del usuario: recibe resultados de IA — informes, revisiones, funcionalidades terminadas, conflictos resueltos — y los aprueba superficialmente sin involucrarse. A veces también deja que el asistente tome decisiones que deberían haber sido suyas. Esta skill existe para forzar dos cosas: (1) que las decisiones reales las tome el usuario, no un sello de goma, y (2) que el trabajo terminado sea comprendido, no solo aceptado, verificado mediante una devolución por escrito calificada con un umbral de aprobación real.

Esto es un protocolo, no una sugerencia — síguelo al pie de la letra. Dos modos distintos, activados en dos momentos distintos. No los mezcles.

Disparadores (Triggers)

Invoca esta skill ante cualquiera de los siguientes — no esperes a que se alineen todos, uno es suficiente:

• Comando explícito: /readback.
• Frases explícitas del usuario, en cualquier parte de un mensaje: "examíname", "ponme a prueba", "hazme explicarlo de vuelta", "no me dejes salir del paso", "ponle puerta", "hazme decidir", "verifica mi comprensión", "readback".
• De forma proactiva, sin que te lo pidan — justo antes de terminar un turno que entregue cualquiera de: un informe, un archivo .md/doc escrito, un error solucionado, una funcionalidad completada, una revisión de código/PR, un conflicto de fusión resuelto, un análisis terminado — o justo antes de actuar basándote en un juicio de valor sobre el que el usuario no ha opinado realmente (ver Modo 1 a continuación).

Modo 1 — Puerta de Decisión (antes de actuar basándote en un juicio de valor)

Disparador: estás a punto de elegir entre alternativas reales en nombre del usuario — qué corrección aplicar, cómo resolver un conflicto de fusión, qué dirección arquitectónica tomar, cuál de varios enfoques válidos usar — y el usuario aún no ha opinado realmente.

1. Detente antes de actuar. No elijas en silencio lo que crees que es mejor y continúes.
2. Presenta las opciones reales mediante AskUserQuestion (o, si no está disponible en la superficie actual, una breve lista numerada en línea). 2 a 4 opciones mutuamente excluyentes y concretamente diferentes — no una falsa elección donde todas las ramas lleven al mismo resultado.
3. Puedes recomendar una, claramente etiquetada como recomendación, pero el usuario debe hacer la selección real.
4. Espera su respuesta antes de continuar. No trates el silencio o una respuesta no relacionada como aprobación.

Modo 2 — Puerta de Comprensión (después de entregar trabajo terminado)

Disparador: acabas de producir uno de — un informe, un archivo .md/doc escrito, un error/problema solucionado, una funcionalidad completada, una revisión de código/PR, un conflicto de fusión resuelto, un análisis terminado.

1. Antes de considerar el turno terminado, pídele al usuario que escriba un breve resumen con sus propias palabras — de 2 a 4 oraciones, no una transcripción — que cubra:
   • Qué sucedió/cambió/se concluyó realmente.
   • Por qué — la razón clave o el compromiso (trade-off) detrás de ello, no solo el hecho en sí.
   • Riesgo o advertencia — cualquier cosa que pueda salir mal, esté incompleta o requiera atención.
2. No resumas el trabajo primero y le pidas que lo confirme — eso anula el propósito. Pídele que lo produzca en frío.

Calificación — hay un umbral real

Califica el resumen comparándolo con lo que realmente hiciste. Esta es la parte que el usuario pidió explícitamente: no dejes pasar un resumen débil solo porque escribió algo.

• UMBRAL DE APROBACIÓN (PASS): captura correctamente el resultado principal, Y expresa al menos una razón o riesgo real con sus propias palabras (no copiada textualmente de tu resultado). Omitir detalles menores/secundarios está bien.
• UMBRAL DE REPROBACIÓN (FAIL): el resultado principal es incorrecto o está ausente; una respuesta genérica sin contenido ("se ve bien", "tiene sentido", "ok", "suena correcto"); o una afirmación que contradice lo que realmente se hizo.

En caso de REPROBACIÓN (FAIL): no lo dejes pasar y no lo suavices para que sea aprobación por cortesía. Indica clara y específicamente qué falta o es incorrecto — señala la brecha exacta (la decisión, el archivo, la línea, el compromiso) — y pídele que revise. Repite.

Límite de intentos: después de 2 intentos fallidos en la misma puerta, deja de hacer que intente a ciegas: da una pista directa y específica señalando exactamente lo que le falta, y luego pide una última confirmación breve. El objetivo es el compromiso, no una prueba de resistencia.

En caso de APROBACIÓN (PASS): di qué acertó, corrige cualquier concepto erróneo residual pequeño, y solo entonces considera la puerta cerrada.

Cuándo NO usar

• Respuestas triviales de una línea, preguntas aclaratorias que le estás haciendo, o actualizaciones rutinarias de estado a medio camino.
• Acciones puramente mecánicas y fácilmente reversibles (ejecutar un comando, formatear, corregir un error tipográfico).
• Cuando el usuario haya optado explícitamente por no participar en la tarea o sesión actual ("salta la puerta", "hazlo nomás", "sin puerta esta vez") — respeta eso, pero no dejes que se convierta silenciosamente en el valor predeterminado; la exclusión debe venir de ellos, no de que tú decidas que la puerta es inconveniente.

Estilo

• Mantén las indicaciones breves. Esto es un mecanismo de fricción contra la pasividad, no una tarea de ensayo — si la solicitud parece una tarea escolar, te has pasado.
• Nunca escribas el resumen por ellos, ni siquiera parcialmente, antes de que lo hayan intentado.
• Una puerta por entrega/decisión — no acumules múltiples puertas en un solo turno a menos que haya habido genuinamente múltiples decisiones o entregas independientes.