From a59d50238dd54abe27994c72b0b5eb0981361b83 Mon Sep 17 00:00:00 2001 From: egutierrez Date: Mon, 22 Jun 2026 11:19:30 +0200 Subject: [PATCH] =?UTF-8?q?feat(commands):=20a=C3=B1adir=20/equal=20?= =?UTF-8?q?=E2=80=94=20espejo=20de=20requisitos=20para=20confirmar=20aline?= =?UTF-8?q?aci=C3=B3n?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Reformula la última tarea pedida de forma detallada y estructurada (objetivo, alcance, entregables, supuestos, criterios de aceptación, fuera de alcance, dudas) para que usuario y Claude confirmen alineación antes de ejecutar. No ejecuta la tarea: solo refleja y pregunta. Co-Authored-By: Claude Opus 4.8 (1M context) --- .claude/commands/equal.md | 81 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 81 insertions(+) create mode 100644 .claude/commands/equal.md diff --git a/.claude/commands/equal.md b/.claude/commands/equal.md new file mode 100644 index 00000000..81fdbfe6 --- /dev/null +++ b/.claude/commands/equal.md @@ -0,0 +1,81 @@ +--- +description: "Espejo de requisitos: Claude reformula con detalle la última tarea pedida (objetivo, alcance, entregables, supuestos, criterios de aceptación, fuera de alcance y dudas) para confirmar alineación antes de ejecutar. No ejecuta nada." +argument-hint: "[opcional: matiz o foco a tener en cuenta al reformular]" +--- + +# /equal — confirmar alineación reformulando la tarea pedida + +Mecanismo de **espejo de requisitos**. Cuando el usuario invoca `/equal`, NO ejecutas la tarea: devuelves tu interpretación detallada y estructurada del encargo más reciente, para que el usuario confirme o corrija antes de que empieces a trabajar. + +El objetivo es eliminar el malentendido silencioso: prefieres gastar un turno reflejando lo que crees que se te pide que arrancar en la dirección equivocada. + +## Qué hacer al invocarse + +1. **Identifica la tarea más reciente que el usuario te ha pedido** en la conversación actual: la última petición de trabajo real, no el `/equal` en sí ni un comando de utilidad anterior. Si hay `$ARGUMENTS`, úsalos como matiz o foco adicional al reformular (p. ej. "céntrate en el alcance" o "asume que es solo el backend"), no como la tarea nueva. + +2. **Reformula esa tarea de forma detallada y estructurada**, con estas secciones (omite una sección solo si es genuinamente no aplicable, no para abreviar): + + - **Objetivo** — qué se quiere conseguir, en una o dos frases claras. El "para qué", no solo el "qué". + - **Alcance / qué incluye** — los trozos concretos de trabajo que entiendes incluidos. Lista, no párrafo. + - **Entregables** — qué archivos, cambios, salidas o artefactos concretos vas a producir. + - **Supuestos** — lo que estás asumiendo por defecto al no estar dicho explícitamente (stack, ubicación, convenciones, datos, alcance temporal). Hazlos visibles para que el usuario los pueda tumbar. + - **Criterios de aceptación** — cómo sabremos que está bien hecho. Condiciones verificables, no deseos vagos. Cuando aplique, golden + edge + caso de error (alineado con `dod_quality.md`). + - **Fuera de alcance** — lo que NO vas a hacer, para acotar expectativas y evitar scope creep. + - **Dudas / ambigüedades a confirmar** — preguntas concretas sobre lo que no está claro. Numéralas para que el usuario pueda responder por número. Si no hay dudas reales, dilo explícitamente ("sin dudas bloqueantes"). + +3. **Cierra pidiendo validación**: una línea clara del tipo "¿Alineado? Corrige lo que no cuadre y arranco." No empieces a trabajar hasta que el usuario confirme. + +## Caso sin tarea previa + +Si **no hay** una petición de trabajo clara que reformular (la conversación está vacía de encargos, o lo último fueron solo comandos de utilidad / charla), NO inventes una tarea. Dilo directamente y pide al usuario que describa qué quiere hacer, ofreciéndole la misma estructura como guía de qué información es útil (objetivo, entregables, criterios). + +## Reglas duras + +- **No ejecutas la tarea.** `/equal` solo refleja y pregunta. Nada de editar archivos, lanzar comandos de trabajo ni delegar a subagentes para "ir avanzando". +- **No inventes requisitos.** Lo que no se ha pedido va a *Supuestos* (marcado como asunción) o a *Dudas* (como pregunta), nunca colado como hecho. +- **Refleja lo que se pidió, no lo que crees que debería pedirse.** Si detectas una mejora obvia, propónla como una duda al final, no la incorpores al objetivo. +- **Sé concreto.** Evita reformulaciones genéricas que valdrían para cualquier tarea. Cita los detalles reales del encargo (nombres de archivos, rutas, tecnologías, cifras que el usuario mencionó). +- Mantén el comando **simple**: es un reformulador de requisitos, no un planificador de implementación ni un generador de tareas. + +## Ejemplo de salida + +Para una petición previa como *"añade un endpoint `/health` al servicio de deploy que devuelva 200 y la versión"*: + +``` +## Objetivo +Añadir un health check HTTP al deploy_server para poder verificar de forma +programática que el servicio está vivo y saber qué versión corre. + +## Alcance / qué incluye +- Nuevo handler GET `/health` en el servidor HTTP de deploy_server. +- Respuesta 200 con un cuerpo JSON que incluya la versión del binario. +- Registro de la ruta en el router existente. + +## Entregables +- Cambio en el código del servidor de `apps/deploy_server/` (handler + ruta). +- Sin migración de BD (no toca schema). + +## Supuestos +- La versión a devolver es la que ya expone el binario (no hay que crear un + sistema de versionado nuevo). +- Formato de respuesta JSON `{"status":"ok","version":"x.y.z"}`. +- Sin autenticación en `/health` (endpoint público de liveness). + +## Criterios de aceptación +- Golden: `GET /health` con el servicio arriba → 200 + JSON con `version`. +- Edge: la versión se lee correctamente aunque el binario se compile sin tag. +- Error: si un subsistema crítico no está listo, devuelve 503, no 200 falso. + +## Fuera de alcance +- Readiness check de dependencias remotas (VPS, SSH). +- Métricas / observabilidad más allá del 200. + +## Dudas / ambigüedades a confirmar +1. ¿`/health` debe comprobar algo real (DB, disco) o basta con responder vivo? +2. ¿La versión sale de un ldflag de build, de un fichero, o de constante? +3. ¿Puerto y router son los que ya usa `deploy_server serve`? + +¿Alineado? Corrige lo que no cuadre y arranco. +``` + +El ejemplo es ilustrativo del **formato y el nivel de detalle**; el contenido real sale siempre de la tarea concreta que el usuario haya pedido en la conversación.