heithmurray/agent-skills

bcp-finish

El paso de finalización para trabajo real. Un modelo lo construyó; un modelo diferente lo ataca; el Operador toma la decisión. Basado en el Protocolo Constructor-Cuestionador v1.7 (https://github.com/heithmurray/builder-challenger-protocol, CC BY 4.0, Heith Murray).

Cuándo

• Ejecútalo antes de solicitar aprobación de finalización para cualquier trabajo más allá de un cambio rápido. No esperes a que te lo pidan.
• Omítelo para trabajo rápido: obvio, pequeño y fácil de deshacer. La verificación enfocada es suficiente.
• Un tema por ejecución: el cambio que estás a punto de entregar.

Roles

• Constructor: tú, el agente que realizó el trabajo. Arreglas o respondes cada objeción.
• Cuestionador: un modelo diferente, ejecutado en modo solo lectura. Encuentra problemas; nunca edita archivos ni escribe texto entregable.
• Operador: el humano que posee el trabajo. Solo el Operador aprueba, acepta un riesgo, extiende el límite de rondas, emite una excepción de verdad o REFRAME, o decide sobre el alcance. Tú actúas como intermediario entre Constructor y Cuestionador, y puedes emitir un RESET — [instrucción] estándar solo por violaciones de formato.

Quién cuestiona a quién

• El Cuestionador siempre es de una familia de modelos diferente al Constructor, iniciado sin interfaz gráfica en modo solo lectura. Los emparejamientos y comandos exactos están en references/tools.md.
• Usa el modelo predeterminado configurado de cada herramienta; no elijas uno.
• Cada llamada es una sesión nueva sin historial compartido. Dale la entrada completa de la ronda cada vez (ver Transferencia).
• Permite hasta 10 minutos por llamada. Cada ronda suele durar de 1 a 5 minutos.

Transferencia (lo que recibe el Cuestionador)

Cada ronda, escribe un prompt con estas partes, en orden:

1. references/challenger-prompt.md, el archivo completo (el rol, las reglas y los formatos).
2. RONDA [n] — SALIDA DEL CONSTRUCTOR — v1.[n-1].
3. Tema: una oración sobre lo que debe lograr este cambio, en las palabras del Operador si las tienes, más los criterios de aceptación.
4. Dónde buscar: la ruta del repositorio, commits base y head, los comandos para ver el diff (por ejemplo git diff <base>..<head>), y los archivos que importan.
5. Evidencia del Constructor: la verificación que ejecutaste y sus resultados.
6. Desde la ronda 2 en adelante: tu Respuesta del Constructor (el Formato de Respuesta del Constructor abajo) y el último Libro de Objeciones del Cuestionador, textualmente.

Nada más. Sin comentarios, sin rondas anteriores más allá del libro.

El Cuestionador puede leer archivos y ejecutar comandos de solo lectura para demostrar sus puntos. Los niveles de evidencia importan: ejecutar el código o las matemáticas supera a citar una fuente, que supera a la opinión.

El bucle

El límite de rondas es 5 a menos que el Operador haya establecido otro antes de la ronda 1. Cuando se alcance el límite sin APROBADO, detente y pregunta al Operador. El Operador puede extenderlo una vez, con una razón: EXTENDER — [ronda actual] a [nuevo límite]. Razón: [el trabajo específico aún pendiente]. No hay segunda extensión; alcanzar el límite nuevamente es un punto muerto.

1. Ronda 1: envía la transferencia. Guarda la respuesta del Cuestionador textualmente como ronda 1.

2. Veredicto REVISAR o FALLAR: responde en el Formato de Respuesta del Constructor:

   • Respuesta al veredicto.
   • Objeciones aceptadas (por ID): lo que cambiaste. Para cada una: "Objeción [ID] era de nivel [X]. Mi revisión cambió [Y]. La proporción es apropiada porque [Z]."
   • Objeciones rechazadas (por ID): razones, con evidencia de igual o mayor nivel.
   • Desafío de objeción débil.
   • Respuestas a suposiciones.
   • Revisiones realizadas.
   • Preguntas abiertas restantes.

   Haz las revisiones y confírmalas en la rama. Luego envía la siguiente transferencia de ronda.

3. Una objeción que cambiaría el alcance, comportamiento o diseño no es tuya para arreglar en silencio. Detente y llévala al Operador como una decisión, con el texto del Cuestionador textualmente.

   • Una especificación o plan que escribiste tú mismo no resuelve el alcance. No rechaces una objeción señalándolo. Solo cuentan las palabras del Operador o una especificación que el Operador aprobó. Si el alcance es la única razón para rechazar, repórtalo como "Se necesita fallo de alcance del Operador".

4. Veredicto APROBAR solo cuenta con una Lista de Verificación de Cierre completada donde el recuento abierto sea cero y el veredicto final sea APROBADO. De lo contrario, trátalo como REVISAR.

5. Límite de rondas alcanzado sin APROBADO: detente y lleva el libro abierto al Operador. Si el Operador extiende (una vez), continúa. De lo contrario, o en el límite extendido, es un punto muerto: pide al Cuestionador una Declaración de Posición Final de un párrafo, escribe la tuya, y lleva ambas al Operador.

6. AUTO-FALLO: si el enfoque en sí mismo está roto, dilo con las tres partes requeridas: (a) qué está roto, (b) por qué tomó el desafío descubrirlo, (c) qué haría que un enfoque diferente funcionara. Llévalo al Operador.

Nunca edites, recortes o suavices una respuesta del Cuestionador. Nunca afirmes que una objeción está resuelta; solo el libro del Cuestionador puede marcarla como resuelta.

Dónde va el registro

• Si el trabajo tiene una carpeta de cambios o un registro de tarea, guarda las rondas allí como BCP-LEDGER.md: cada respuesta del Cuestionador y cada Respuesta del Constructor, en orden.
• De lo contrario, guárdalas en una carpeta temporal fuera del repositorio e incluye el libro final en tu informe.
• No crees nuevas carpetas de nivel superior para esto.

Informe al Operador (aprobación de finalización)

• Los modelos utilizados para Constructor y Cuestionador, y el número de rondas.
• La versión final y el veredicto final del Cuestionador.
• El Libro de Objeciones final, textualmente.
• Las concesiones del Cuestionador y su autoevaluación de riesgos no planteados, textualmente.
• Tu evidencia de verificación.
• Cada interpretación que hiciste donde la solicitud era ambigua (por ejemplo "los días 6–29 no cobran nada"), para que el Operador pueda confirmarla o corregirla.
• Cualquier cosa que necesite la decisión del Operador: punto muerto, AUTO-FALLO, fallos de alcance, objeciones que cambien el alcance, riesgos a aceptar.
• Luego pregunta si seguir adelante o no. El push, merge y publicación esperan la decisión del Operador.

Si el Cuestionador no puede ejecutarse

1. Reintenta una vez. Si un error del modelo menciona un modelo no soportado, repórtalo; no cambies de modelo silenciosamente.
2. Si la otra herramienta aún no está disponible, ejecuta el mismo bucle con el comando sin interfaz gráfica y solo lectura de tu propia herramienta como Cuestionador (ver references/tools.md). Es una sesión nueva sin contexto compartido.
3. Etiqueta todo el resultado como AUTO-CUESTIÓN en el informe, y di por qué el segundo modelo no estaba disponible. Una auto-cuestión comparte los puntos ciegos del Constructor, por lo que el Operador debe darle menor peso.
4. Nunca omitas el paso en silencio.