r3xsean/see-it-through

Toma un cambio de código desde la solicitud del usuario hasta donde debe terminar, con otro modelo como revisor. El usuario decide dos veces: el enfoque, en el explicador, y el resultado, en el mensaje de envío. Todo lo demás depende de ti.

El otro modelo es el modelo más nuevo, en orchestrator_capabilities, de la familia que el usuario nombró, al esfuerzo que nombró. El mismo modelo y esfuerzo ejecutan cada ida y vuelta, bucle de código y revisión a continuación, excepto el debate de una decisión clave. Si falta la familia o el esfuerzo, pregúntalo y no hagas nada más hasta que respondan.

Un ejecutor defiende el enfoque en el paso 3 en tu lugar (el skill back-and-forth). A menos que el usuario nombre un ejecutor: el modelo Fable más nuevo a esfuerzo medio, debatiendo con el otro modelo; para una decisión clave, el modelo Fable más nuevo a esfuerzo alto, debatiendo con el modelo Astra más nuevo a esfuerzo alto en lugar del otro modelo. Una decisión clave es aquella donde se activa un disparador de una pregunta estructural en design.md y puedes plantear una pregunta cuya respuesta podría cambiar el enfoque. Cuando el modelo de un ejecutor o su compañero no está disponible, dícelo y defiende el enfoque tú mismo con el otro modelo.

1. Destino y reglas

Determina dónde termina el cambio: un cambio local probado, una rama enviada, un PR abierto, fusionado o desplegado. Pregunta solo cuando no esté claro y la respuesta cambie el trabajo. Decir "see it through" no aprueba ningún envío, PR o despliegue; la aprobación del mensaje de envío sí lo hace.

Las reglas del repositorio que estás cambiando, y cualquier archivo de proceso al que el usuario te señale, prevalecen donde difieran de este skill.

Un cambio ya construido. Cuando el usuario dice que el cambio ya está hecho, lo construido es el enfoque, y el mensaje de envío es la primera aprobación: no envíes ningún explicador ni ejecutes ningún ida y vuelta. En lugar de los pasos 2 y 3:

• Fija la base: para una rama no fusionada, su base de fusión con la rama en la que se fusiona, tomada después de su última fusión de esa rama; una vez fusionada, el commit anterior al cambio. Pregunta cuando no esté claro. Cuando el cambio ya está fusionado, el destino es a dónde van los commits de seguimiento de esta ejecución; pregunta cuando no esté claro.
• Escribe la solicitud a partir de las palabras del usuario y de lo que el cambio dice de sí mismo (mensajes de commit, texto del PR), marcando lo que inferiste.
• Encuentra las comprobaciones que fallan en un árbol de trabajo de la base y pasan en el cambio, comenzando con las pruebas que el cambio ya tiene (ejecútalas en la base con solo los fragmentos de prueba y arnés del cambio aplicados), y escribe una solo para un comportamiento prometido que ninguna de ellas demuestre; para un cambio sin fallo que mostrar, como una optimización o una refactorización, una comprobación de lo que promete. Establece el nivel como en el paso 2. Mantén como la línea base de aceptación, como el paso 4 la mantiene, la menor cantidad de esas comprobaciones que demuestren cada comportamiento que el cambio promete, anotando cuáles fueron escritas después del cambio; las otras pruebas del cambio permanecen abiertas para simplificar.md.
• Escribe el enfoque como está construido en un archivo: qué cambió, el fundamento de design.md y su pregunta estructural respondida sobre lo construido, y la comprobación de fallo del paso 3.

Luego continúa en el paso 4 desde mostrar que la reproducción pasa, y da a ese bucle de código esa base y ese archivo como su Enfoque. El mensaje de envío dice que no se aprobó ningún explicador, y lleva cualquier alternativa estructural y cualquier hallazgo que cambie lo que el usuario obtiene.

2. Reproducir

Para un error, reprodúcelo en la base antes de escribir una corrección: una prueba que falle, y, cuando un usuario pueda ver el error, el producto en ejecución que lo muestre, capturado como dice capture.md, a mano cuando el flujo de verificación aún no pueda capturar. Para una funcionalidad, escribe lo que el usuario debería ver o poder hacer. Cuando no puedas reproducir un error, díselo al usuario antes de construir una corrección, y escribe cualquier cosa que digas al respecto como "de la lectura del código (no probado)". Una comprobación que no encuentra nada cuenta solo una vez que la hayas visto encontrar la cosa cuando está presente.

No construyas ninguna protección para una ruta de fallo que no hayas reproducido; enumérala en el explicador como un seguimiento.

Reproduce y demuestra a través del skill de verificación del repositorio: .agents/skills/verify/ en el repositorio, o donde lo ponga el AGENTS.md del repositorio. Cuando no haya ninguno, o no cubra el flujo que necesitas, reproduce manualmente por ahora y haz que construir esa cobertura con el skill make-verifiable sea parte del enfoque.

Luego establece el nivel. Completo cuando el comportamiento cambiado alcance persistencia, concurrencia, autorización, migraciones, un contrato público, efectos destructivos o propiedad de estado compartido, o cuando aún no puedas decir cómo se alcanza el código cambiado o qué tan bien lo cubren las pruebas; juzga por los llamadores y escritores de estado que encuentres, no por los nombres de archivo. Ligero de lo contrario. Una ejecución ligera que revela uno de estos se vuelve completo.

3. Diseño y el explicador

Lee design.md y haz lo que pide antes de elegir un enfoque. En una ejecución completa, ve y vuelve con el modelo sobre el enfoque (el skill back-and-forth), con las estimaciones de proporción de design.md en su Contexto como premisas a verificar y una versión más pequeña y ningún cambio entre las opciones; en una ejecución ligera, hazlo solo cuando se activen los disparadores de design.md o los enfoques fuertes difieran materialmente, y de lo contrario escribe el enfoque tú mismo. Dale al ejecutor, en el Contexto, tu fundamento con sus referencias, lo que reprodujiste y lo que solo leíste, y una ruta para su registro en el bloc de notas temporal o carpeta temporal de la sesión; en la Pregunta, que escribes a partir de la solicitud, pregunta también por dónde aterriza el cambio, incluidos los llamadores y casos hermanos, los casos de aceptación, y lo que te deja a ti. Cuando una pregunta de diseño sea un hecho que podrías observar ejecutando algo, resuélvelo con un experimento desechable en un checkout aislado o datos temporales, no preguntando al usuario; el experimento no envía nada.

Luego escribe la comprobación de fallo: revisa las Condiciones en el encabezado breve del skill code-loop, más quién dependía del comportamiento que estás cambiando, y para cada una que aplique, nombra la prueba que lo cubrirá o la limitación que aceptas.

Envía al usuario el explicador, en lenguaje sencillo, bajo estos encabezados, en orden. Di cada cosa una vez.

• El problema: lo que un usuario ve hoy, quién lo sufre y con qué frecuencia (observado o estimado; sin informes significa desconocido, no raro), por qué importa, y tu reproducción, con su captura cuando la tenga; para una funcionalidad, lo que falta hoy. Cuando el usuario pidió el cambio, abre con sus palabras.
• Por qué ocurre: la causa, en términos sencillos; para una funcionalidad, lo que se interpone hoy. Deja este encabezado fuera para una funcionalidad cuando nada se interponga.
• Qué cambia: lo que el usuario verá o podrá comprobar cuando esté hecho, y lo que está fuera del alcance. Cuando algo que cambiaría el trabajo falte, pregúntalo aquí.
• El enfoque: qué cambia en el código y dónde, cómo lo probarás, incluido cualquier trabajo de make-verifiable y qué comprobaciones se envían con el cambio o permanecen como evidencia, qué cuesta enviar y mantener y por qué vale la pena el alcance y el daño bajo El problema, y las entradas de comprobación de fallo que a un revisor le importarían.
• Alternativas consideradas: cada alternativa fuerte, la opción estructural de design.md entre ellas siempre que exista una creíble, cada una con por qué perdió.
• Lo que un revisor puede preguntar: cada pregunta probable, con su respuesta.

Luego para: no construyas nada hasta que el usuario apruebe. Una aprobación simple en cualquier redacción te permite construir. Cualquier otra cosa va palabra por palabra al mismo ida y vuelta como un intercambio adicional, más allá de su límite de intercambios, y vuelve como un explicador revisado; para de nuevo. En una ejecución ligera sin ida y vuelta, revisa el explicador tú mismo y para de nuevo.

La aprobación cubre el explicador tal como está escrito. Cuando una prueba, una demo o una revisión cambien lo que el usuario obtiene, su comportamiento visible, compatibilidad, alcance, la acción que tomarás para enviarlo, o una compensación que el explicador aceptó, cita la oración que falsifica, resuélvelo con el modelo, envía un explicador revisado que diga qué cambió, y para de nuevo. Descubrimientos más pequeños, como usar un ayudante interno diferente, van en el mensaje de envío bajo "qué cambió desde".

4. Construir y probar

Antes de cambiar el comportamiento, conserva la reproducción y cada comprobación de aceptación que pueda ejecutarse antes de que exista el cambio: confirma las que el explicador envía, y guarda el resto, o todas cuando no se confirmará nada, como un parche fuera del repositorio. Juntos son la línea base de aceptación, y todo se ejecuta de nuevo en el candidato final: cualquier edición posterior va al bucle de código y al mensaje de envío con su diff y si cambia el comportamiento prometido.

Construye el enfoque aprobado, en el orden que establece design.md. Cuando el cambio altere un flujo que cubre el skill de verificación, actualiza ese flujo en el mismo cambio. Muestra que la reproducción del paso 2 pasa, a través del skill de verificación y en el producto en ejecución cuando el usuario pueda verlo. Luego simplifica el diff como dice simplify.md. Luego ejecuta un bucle de código con el modelo sobre el diff completo (el skill code-loop), dándole la solicitud del usuario, o el resumen que la representa, como la Solicitud, el explicador como el Enfoque, con el registro del ejecutor cuando lo haya, la línea base de aceptación como la Aceptación, y el nivel.

En el candidato final, cuando un usuario pueda ver o hacer lo que cambió, captúralo a través del flujo de verificación, extendiendo el flujo con make-verifiable cuando no pueda, y para un error captura el mismo escenario en la base a través del mismo flujo, para que el antes y el después coincidan. Elige, haz y revisa la captura como dice capture.md, y comprueba que muestra lo que dirás que muestra. Una captura muestra el cambio y las comprobaciones lo demuestran, así que una captura de la base o de una ejecución fallida nunca se considera un pase. Un cambio sin nada que ver no obtiene captura.

5. Redacción

Redacta el texto del PR, issue o release a partir de las plantillas del proyecto, con las capturas donde la plantilla tenga espacio para ellas, o bajo un encabezado propio. En GitHub, adjúntalas cuando publiques con gh pr create --attach (o gh pr edit) a menos que el repositorio tenga su propia herramienta; cuando salga con código de error distinto de cero, busca el PR antes de reintentar, ya que puede que ya exista. Antes de que salga cualquier texto público que afirme un hecho (una descripción, una respuesta, una actualización de estado), un revisor fresco del modelo lo verifica contra la evidencia, las capturas (una grabación como sus fotogramas e informe de ritmo) y el diff: cada afirmación verdadera y respaldada, cada casilla marcada verdadera. Corta una afirmación que la evidencia no respalde; no la matices.

Antes de cada envío, vuelve a ejecutar la comprobación detrás de cada casilla marcada y cada afirmación, y rehaz cada captura, que el cambio desde entonces podría afectar.

6. Mensaje de envío

Envía al usuario: un resumen de dos o tres oraciones del explicador, qué cambió desde entonces, la evidencia, las capturas, la redacción, el diff y la acción exacta que tomarás con la aprobación. Cuando el bucle de código terminó con disputas no resueltas, comienza con ellas: cada afirmación, lo que mostró cada lado, y qué aprueba el envío con ella. Antes de enviarlo, rehaz la verificación de superposición de design.md. Para hasta que lo aprueben.

7. Hasta el destino

Toma la acción aprobada, luego lleva el cambio a su destino:

• Antes de cada envío y antes de actuar sobre una notificación, obtén la cabeza remota y verifica el estado actual del cambio. Construye sobre los envíos de otros, comparando árboles en lugar de hashes de commit; no reemplaces su trabajo con una versión local obsoleta. Cuando el cambio aterrice, se cierre o sea reemplazado por la versión de otra persona, compara lo que llegó al destino con tu última cabeza verificada y hallazgos abiertos. Informa qué difiere o no llegó, sin volver a agregar lo que eliminaron a propósito.
• Cada hallazgo de revisión, en línea o en el cuerpo de una revisión, léelo completo, recibe una corrección o una razón de una línea; uno que también ocurra en la base se juzga como code-loop juzga un hallazgo preexistente. Una corrección que cambie el comportamiento obtiene un bucle de código.
• Cuando un hecho demuestre que el texto publicado está equivocado, corrige el texto.
• Una solicitud que cambie el alcance o el enfoque vuelve al paso 3 y, una vez construida, a un nuevo mensaje de envío; una que se aplique más allá de este cambio va al usuario cuando llegue, con su enlace: hacerlo aquí no lo hace en otro lugar.
• Para un despliegue, ejecuta el flujo de verificación contra lo que está desplegado.

8. Lecciones

Cuando el usuario, un revisor de PR o cualquier cosa después del envío detecte un problema que el bucle de código pasó por alto, o el bucle de código encontró un bloqueador o debería haberlo hecho, agrega una entrada a .agents/lessons/log.md en el repositorio que cambiaste; para un repositorio que el usuario no posee, en la carpeta que contiene su proceso para él. Cada entrada: la fecha, el cambio, qué fue detectado y por quién, el módulo, la clase de error y la causa.

Luego lee el registro. Una lección que una comprobación podría detectar, vista dos veces, se convierte en una verificación de lint, tipo, prueba o verificación; una que necesita juicio, vista dos veces, se convierte en una línea en el AGENTS.md del repositorio; dos entradas en un módulo, o dos de una clase de error en cualquier módulo (como estado que otra operación cambia durante un await), se convierten en una pregunta estructural, nombrando la causa que comparten antes de que se proponga cualquier refactorización. Enumera cada una como un seguimiento en tu mensaje final; una refactorización se ejecuta como su propio see-it-through.

Hecho cuando el cambio está en su destino, o cuando has informado el bloqueador exacto y lo que queda, y la entrada de lecciones, si corresponde, está escrita.