# harness

> Original en inglés. Traducción generada por IA, no por el autor. [Leer el original en inglés](https://www.ferueda.com/projects/harness).

> Kit personal para agentes con skills reutilizables, flujos de trabajo y una fábrica de software mínima.

Creé Harness para mantener un flujo de desarrollo consistente entre proyectos. Reúne las skills y los flujos de revisión que uso a diario, junto con Factory: un camino persistente desde un elemento de trabajo hasta un pull request revisado.

Factory se encarga de la clasificación inicial, la planificación, la implementación y la revisión, un paso a la vez. Registra cada resultado, se detiene cuando necesito tomar una decisión y solo publica el commit exacto que pasó la revisión. Nunca hace merge del pull request.

[Ver el código en GitHub](https://github.com/ferueda/harness)

## Cómo encajan las piezas

- **Factory.** El recorrido completo desde un elemento de trabajo hasta un pull request revisado. Parte de un issue de Linear o de un elemento local, pasa por planificación o va directamente a implementación, ejecuta revisiones y puede publicar el commit exacto que las pasó. Cada ejecución procesa como máximo un paso pendiente y termina.
- **Revisiones.** `change-review` y `plan-review` también funcionan por separado. Usan roles de revisión independientes y dejan hallazgos estructurados y artefactos en el repositorio de destino.
- **Skills.** Componentes reutilizables en el formato [Agent Skills](https://agentskills.io/) para planificación, diagnóstico, traspasos, revisiones y otras tareas repetibles. Algunas incluyen sus propios scripts, como la CLI `sessions` para buscar trabajo anterior.
- **Proveedores y ejecutor.** Cursor y Codex usan los mismos flujos. La CLI gestiona la configuración del repositorio y ejecuta el trabajo. Las revisiones independientes escriben en `.harness/runs/`; Factory conserva su estado y evidencia en un almacén persistente separado.

## Cómo lo uso

Para un cambio pequeño, ejecuto `change-review` antes de abrir o integrar un pull request. Ejecuta revisores de implementación y de calidad de código sobre el mismo diff. Corrijo lo que importa y lo ejecuto de nuevo.

Para trabajos más grandes, empiezo con un issue de Linear. Factory lleva ese mismo elemento por clasificación, planificación, implementación y revisión. Si una revisión requiere cambios, se detiene y me pide que ajuste el trabajo o vuelva a revisar el mismo candidato. Cuando el candidato pasa, le indico a Factory que publique el pull request. Sigo haciendo el merge yo mismo.