Stop Chatter
Conserva únicamente lo que el usuario ha solicitado en esta ocasión. Una corrección debe modificar el objetivo de trabajo, no convertirse en nuevo contenido acerca del error anterior.
Elige el modo más ligero
- Modo ligero (predeterminado): Úsalo para correcciones ordinarias y complementos posteriores. Mantén el objetivo en el contexto de trabajo y sigue las reglas a continuación. No crees estados transitorios ni otros artefactos del flujo de trabajo. Leer este skill o reafirmar el plan en el chat no es entrega; modifica los archivos.
- Modo protegido: Úsalo solo cuando el usuario lo solicite explícitamente, o cuando el mismo elemento retirado ya haya vuelto a aparecer y el alcance de la verificación pueda limitarse a ese residuo. Lee references/protocol.md antes de modificar entregables, inicializa una vez, luego ejecuta el verificador antes de la entrega.
No cambies al modo protegido solo porque la tarea sea larga, toque Git o abarque múltiples archivos. Una vez que esta corrección finalice, la continuación ordinaria vuelve al modo ligero. Una transferencia explícita no finalizada puede reutilizar el mismo estado de tarea; no escribas la lista de elementos retirados en memoria duradera.
No menciones Stop Chatter, un modo de cumplimiento ni el historial de correcciones en el entregable. Mantén útil el resumen de finalización de la conversación: reporta cambios materiales, verificaciones y límites conocidos cuando el usuario los necesite para alinearse sobre lo ocurrido.
Recompila el objetivo actual
Después de cada corrección:
- Reescribe el objetivo como el resultado positivo actual.
- Conserva solo los requisitos aún activos. Un elemento retirado se elimina, no se conserva como requisito negativo.
- Separa las meta-restricciones como conciso, eficiente o no construir en exceso. Estas dan forma a la ejecución y no deben convertirse en títulos, etiquetas, copia de UI, nombres de versión ni preferencias duraderas.
- Conserva exclusiones explícitas solo cuando la ausencia sea en sí misma un contrato externo activo, una propiedad de seguridad o un criterio de aceptación.
Coloca ese objetivo reescrito en los archivos antes de eliminar residuos. Que esta ronda no haya mencionado algo ≠ retirarlo. Retirar un elemento no autoriza eliminar características aún activas ni limpiar el resto del proyecto. No uses la conversación en bruto como especificación continua después de este paso.
Qué puede eliminarse
Solo el contenido explícitamente retirado, y los derivados que la evidencia visible muestre que existen únicamente para servirlo, entran en el conjunto de limpieza. Los archivos existentes y las ediciones previas del usuario se mantienen por defecto. Las características aún válidas, las propiedades de seguridad y los contratos de compatibilidad se mantienen. Si el origen de un archivo no está claro, consérvalo.
Una vez que el artefacto principal coincida con el objetivo actual, busca una vez los derivados que existen únicamente para servir al elemento retirado: registro de cambios conmemorativo o notas de versión para esta corrección, pruebas cuya única función sea demostrar que el elemento retirado está ausente, registros de la opción rechazada y archivos nombrados según la característica retirada. Esa pasada no es una limpieza a nivel de proyecto.
Pregunta solo cuando la ambigüedad bloquee la entrega. No agregues un paso de confirmación para cada archivo.
No agregues una prueba únicamente para conmemorar una corrección o para demostrar que un elemento no solicitado está ausente. Conserva una prueba negativa solo cuando un requisito activo haga que esa ausencia sea observable externamente o crítica para la seguridad. Las pruebas de contrato de operaciones de archivos del propio verificador pueden permanecer.
Rastrea las operaciones de archivos de esta ronda
Cada archivo agregado o modificado en esta ronda debe corresponder al menos a un requisito activo. Asignar una ruta como permitida para modificar no autoriza eliminar todo el archivo. Elimina un archivo completo solo cuando la evidencia visible de la tarea respalde esa eliminación.
Los comentarios explican propiedades no obvias del código que aún existe. El texto de PR y de versión describe el estado positivo resultante. La UI contiene contenido de producto orientado al usuario, nunca requisitos internos ni historial de correcciones. No agregues números de versión, afirmaciones de versión inmutable, hashes ni ceremonias adicionales a menos que el usuario o el proceso de versión lo requieran.
Mantén la memoria limpia
Trata las correcciones como locales a la tarea por defecto. Persiste una solo cuando el usuario lo solicite explícitamente como memoria duradera o establezca claramente una preferencia estable entre tareas. Almacena el comportamiento positivo abstracto y el alcance, no el ejemplo rechazado. Después de las ediciones, escanea los archivos restantes, incluida la memoria, en busca del elemento retirado y sus alias en otros idiomas o nombres cercanos; elimina solo esos rastros.
Verificación protegida
En el modo protegido, inicializa antes de modificar los entregables. Si ya existe estado de tarea válido para esta raíz, reutilízalo; no lo sobrescribas ni reinicies la línea base de inicio. Si el estado es inválido o pertenece a una raíz diferente, detente en lugar de reutilizarlo o reemplazarlo.
python3 <skill-dir>/scripts/stop_chatter.py init --root .
Reemplaza los valores de plantilla con el objetivo actual, las rutas de agregar/modificar más estrechas, las rutas exactas must_remove respaldadas por evidencia visible, las etiquetas y alias retirados, y los marcadores de fuga de meta-instrucciones. No edites la línea base capturada por init. Establece ready en true solo después de que esos valores estén actualizados. Luego verifica una vez:
python3 <skill-dir>/scripts/stop_chatter.py check --root . --cleanup-state-on-pass
En caso de éxito, este mismo comando elimina solo .stop-chatter/state.json. No ejecutes una segunda verificación exitosa ni un comando de limpieza separado. No elimines cachés de intérprete, cachés de prueba ni otros archivos de usuario para "limpiar el estado". En caso de fallo, el estado se conserva; corrige solo problemas de alcance o residuo evidenciados, luego vuelve a ejecutar como máximo una vez.
El verificador solo informa. No elimina ni restaura entregables, y no decide la propiedad del producto. Una verificación aprobada significa que las comprobaciones configuradas pasaron, no que la implementación sea correcta ni que no quede nada.
Si una transferencia activa aún necesita el estado, omite --cleanup-state-on-pass y elimina el archivo cuando finalice esa transferencia. Nunca promuevas el libro mayor transitorio de elementos retirados a la memoria.
Para rutas de instalación e invocación específica del host, lee references/host-setup.md solo al instalar o diagnosticar el descubrimiento.
Entrega el resultado
Detente solo cuando los archivos coincidan con el objetivo actual. Devuelve el artefacto solicitado más suficiente información de finalización para que el usuario entienda los cambios materiales, la validación y los límites conocidos. No suprimas información útil solo para que la respuesta parezca limpia. Mantén el artefacto en el lenguaje del estado actual: no lo llames versión corregida, limpia, concisa, sin X o de estado final. En la respuesta, menciona el historial eliminado cuando el usuario solicite un rastro de auditoría o cuando la eliminación sea materialmente relevante para el alcance, la migración, la seguridad o la compatibilidad.