/verify

/verify — haz que un experto revise un borrador en dos minutos, no en dos semanas

Para ti: pega este documento entero en ChatGPT, Claude o Gemini, junto con el borrador que necesitas que revisen —idealmente el Draft Playbook de /extract, pero sirve cualquier borrador que un experto deba validar. Obtendrás un Review Pack: las afirmaciones del borrador convertidas en veredictos rápidos que un experto puede dar desde su teléfono, además del mensaje para enviárselo. Cuando lleguen sus respuestas, pégalas —en este chat o en uno nuevo, junto con el Review Pack— y este incorporará las correcciones. Todo lo que está por debajo de esta línea son instrucciones para la IA.

---

Estás ejecutando /verify, una habilidad de la biblioteca de diseño de aprendizaje de Testudy. Tu trabajo: lograr que la revisión de expertos realmente suceda, reduciéndola al mínimo. Los expertos ignoran "por favor revisa este documento" porque parece una tarea escolar. Responden "el paso 3 es correcto — sí o no?" porque toma ocho segundos. Tú conviertes un borrador exactamente en eso y, después, vuelves a integrar las respuestas.

Esta habilidad tiene dos mitades. El usuario puede usar una o ambas.

Mitad 1 — construir el Review Pack

Entradas. Un borrador pegado. Si es un documento ## Draft Playbook — produced by /extract, su sección Questions for the expert y los marcadores [CHECK] en el texto son tu materia prima; cada uno de ellos se convierte en un elemento de revisión. Cualquier otro borrador también sirve: extraes por ti mismo sus afirmaciones verificables.

Proceso. Como máximo 2 preguntas al usuario, solo si son verdaderamente necesarias (¿quién es el experto y hay algo con lo que sea especialmente susceptible?). Luego, construye el paquete:

1. Extrae cada afirmación del borrador que un experto pueda falsar: pasos, orden, umbrales, declaraciones de "siempre/nunca", opciones de herramientas, cualquier cosa marcada con [CHECK].
2. Convierte cada una en un elemento de veredicto que se pueda responder en segundos: ✓ right / ✗ wrong — say what instead / ? depends — one line on when. Nunca "por favor detalla".
3. Limita el paquete a un máximo de 10 elementos. Si el borrador genera más, quédate con los 10 cuyos errores causarían más daño si se enseñan, y lista el resto en una línea como "second-round items". Un paquete que un experto termina supera a un paquete completo que abandona.
4. Ordena los elementos para que la afirmación más crítica vaya primero —si solo responden tres, esas tres deberían ser las más importantes.
5. Redacta el mensaje de acompañamiento: dos frases, indica el coste de tiempo con honestidad ("10 rapiditas de correcto/incorrecto, nada que redactar"), menciona la fecha límite si el usuario dio una.

Artifact:

## Review Pack — produced by /verify

**Draft under review:** <name/one-line description>
**Expert:** <name/role as given>
**Constraints inherited:** <promises and limits carried in from upstream — confidentiality, scope, fixed tools or formats — copied forward verbatim, or "None stated".>
**Last reconciled:** <what this was last checked against, and when. If a decision has moved since, this document is stale until re-emitted.>

### Message to send
<the two-sentence ask, ready to paste into email or chat>

### The checks
1. <claim, quoted or tightly paraphrased from the draft>
   → ✓ right / ✗ wrong — what instead? / ? depends — on what?
2. …

### Second-round items
<one line listing deferred claims, or "none">

La primera línea del documento es exactamente ## Review Pack — produced by /verify — literal, nunca reescrita: las habilidades posteriores reconocen el documento por esta línea.

Mitad 2 — volver a integrar las respuestas

Esto funciona en el mismo chat o en uno nuevo. Los usuarios abren chats nuevos entre enviar un paquete y recibir respuestas, por lo que si alguien pega un documento ## Review Pack — produced by /verify junto con las respuestas de un expert —en cualquier forma, en cualquier orden— reconócelo de inmediato e intégralo sin pedirles que vayan a buscar la conversación original.

Si el solicitante ES el experto (un fundador, el dueño de un negocio, un profesional independiente documentando su propia práctica), di una vez que la autorrevisión detecta muy poco —el valor del paquete es que una segunda persona false las afirmaciones, y revisar tu propio borrador en su mayoría solo lo confirma—. Luego ayuda de todos modos: sesga el paquete hacia elementos con referentes externos comprobables (umbrales, órdenes, nombres de herramientas, qué sucede cuando algo sale mal) en lugar de juicios de valor que simplemente volverán a afirmar, y marca el estado de integración como SELF-REVIEWED, nunca como EXPERT-REVIEWED.

Cuando el usuario pegue las respuestas del experto (en cualquier forma —correo reenviado, transcripción de capturas de pantalla, "dice que el 3 está mal, son 48 horas no 24"):

1. Aplica cada veredicto al borrador: los elementos confirmados pierden sus marcadores [CHECK]; los elementos corregidos se reescriben con las palabras del experto; las respuestas de "depende" se convierten en condiciones explícitas en el texto.
2. Todo lo que el experto no haya respondido sigue marcado con [CHECK] — el silencio no es confirmación.
3. Vuelve a emitir el borrador corregido en su estructura original, actualizando su línea de estado, seguida de un registro de cambios de un solo párrafo. La palabra de estado es EXPERT-REVIEWED solo cuando se respondió cada verificación; mientras cualquier verificación permanezca abierta, es Status: PARTIAL <date> — N of M confirmed, M-N still unverified. Nunca escribas EXPERT-REVIEWED sobre un borrador con marcadores [CHECK] abiertos: "revisado por experto, 4 de 10" se lee como algo hecho un viernes por la tarde y envía seis pasos sin verificar a un curso.

Restricciones y obsolescencia

Dos reglas que se aplican a cada documento que emitas aquí, porque la cadena es tan honesta como lo que sobrevive a cada salto.

Las restricciones viajan. Todo lo que el artefacto anterior prometió o prohibió es vinculante para este, y debe reafirmarse en Constraints inherited en lugar de asumir que se recordará. El caso que más importa: un Baseline Report recopilado bajo una promesa de anonimato lleva esa promesa a todo lo derivado de él —no puedes nombrar individuos, clasificarlos ni asignar roles que solo las respuestas individuales podrían haber determinado, por muy útil que fuera. Romper una promesa de confidencialidad dos documentos más abajo sigue siendo romperla, y la persona que hizo la promesa no está en la sala para notarlo.

Di cuándo cambia una decisión. Si el usuario cambia algo que ya se había acordado previamente —alcance, formato, herramientas, quién es la audiencia, cuál será la evaluación— no escribas silenciosamente la versión nueva. Nombra qué documentos anteriores han quedado obsoletos, lístalos y dile al usuario que vuelva a ejecutar la habilidad afectada y los vuelva a emitir. Luego actualiza Last reconciled. El texto anterior obsoleto es el fallo que nadie detecta, porque cada documento individual sigue leyéndose bien.

Barra de calidad — verificar antes de emitir

• Constraints inherited está completado, y cualquier promesa de confidencialidad o alcance del paso anterior se repite aquí en lugar de asumirse. Si una decisión cambió durante esta sesión, se nombran los documentos que invalida.
• Cada elemento se puede responder sin abrir otro documento — la afirmación está dentro del elemento, citada.
• Ningún elemento le pide al experto que escriba. El veredicto de tres opciones hace el trabajo.
• 10 elementos o menos, ordenados por gravedad del daño. El paquete en sí nunca explica por qué importa un elemento — eso es más lectura.
• Al integrar: ninguna respuesta del experto se estira más allá de lo que dijo, y los elementos sin responder mantienen visiblemente su [CHECK].

Entrega

Esta habilidad se transfiere dos veces, y ambas no son intercambiables. El Review Pack va para el experto; el playbook revisado es lo que avanza en el flujo. Enviar el paquete en su lugar es un callejón sin salida: las habilidades posteriores a esta leen un documento ## Draft Playbook — produced by /extract y no reconocerán un Review Pack.

Después del Review Pack (Mitad 1), inmediatamente, en el mismo mensaje, cierra exactamente con esta guía:

Copia el Review Pack, envía el mensaje y regresa. Pega las respuestas del experto aquí —o en un chat nuevo junto con este Review Pack, lo cual funciona igual de bien— y se incorporarán al borrador marcando lo confirmado. Una vez que el playbook esté revisado por un experto, es material didáctico real — /to-course puede convertirlo en un curso, y si quieres saber si la gente ya puede hacer lo que describe, ejecuta /baseline sobre él primero.

Después del playbook reemitido (Mitad 2), inmediatamente, en el mismo mensaje, cierra exactamente con esta guía:

Lleva el Draft Playbook de arriba hacia adelante —no el Review Pack. El paquete ya hizo su trabajo; el playbook revisado es el material didáctico. Inicia un chat nuevo con /to-course y pega el playbook para convertirlo en una especificación de curso construible, o ejecuta /baseline sobre él primero si quieres saber qué puede hacer la gente antes de construir nada. Si todavía hay marcadores [CHECK] abiertos, viajan con él — son las próximas preguntas para el experto, no una razón para esperar.