desarrollo-impulsado-por-intencion

Desarrollo Impulsado por Intención

Producir criterios de aceptación útiles sin convertir la especificación en un ritual. Inspeccionar primero el contexto disponible, exponer la ambigüedad genuina y elegir métodos de verificación que se ajusten al trabajo y su riesgo.

Cuándo Activarla

• El usuario pide aclarar una funcionalidad, definir criterios de aceptación o reducir el riesgo de un cambio antes de implementarlo
• La solicitud afecta seguridad, autenticación, datos persistentes, migraciones, API externas o cumplimiento normativo
• El usuario desea preparar un artefacto de entrega para otro agente o equipo
• La solicitud es lo suficientemente ambigua como para que el resultado esperado no sea aún observable o comprobable
• El usuario invoca explícitamente esta skill con /desarrollo-impulsado-por-intencion

No activarla para ediciones triviales, correcciones simples de una línea, sesiones activas de depuración, solicitudes de revisión de código o solicitudes de implementación cuyas condiciones de aceptación ya estén claras.

Cómo Funciona

1. Inspeccionar el contexto primero — leer el repositorio, la documentación, los esquemas y la infraestructura de pruebas para obtener datos técnicos antes de hacer cualquier pregunta, considerando que las restricciones de producto/negocio solo pueden provenir del usuario o de un artefacto de producto
2. Elegir la profundidad — seleccionar Captura Rápida (3-7 criterios, riesgo bajo/moderado) o Informe de Aceptación Completo (seguridad, datos, migración, cambios entre sistemas) según el perfil de riesgo
3. Preguntar mínimamente — solo hacer preguntas cuyas respuestas no puedan inferirse y que cambien materialmente el alcance o el comportamiento
4. Redactar criterios observables — cada AC-NNN describe una condición inicial, un desencadenante, un resultado esperado, un efecto secundario prohibido, un método de verificación y una prioridad; sin palabras vagas como "correctamente" o "de forma segura" sin evidencia
5. Proceder o entregar — para solicitudes claras sin riesgos bloqueantes, registrar los criterios y continuar; para cambios riesgosos, presentar los bloqueos y esperar confirmación
6. Gestionar la revisión — si un AC falla durante la implementación debido a restricciones arquitectónicas, marcarlo como [revisado], actualizar el alcance o el método de verificación, incrementar el número de revisión y volver a presentar solo los criterios modificados

Ejemplos

Captura Rápida — "Añadir exportación CSV al panel de control"

Objetivo: Los usuarios autenticados pueden descargar los datos del panel de control como un archivo CSV.
Dentro del alcance: Exportación de las filas actualmente filtradas; el nombre del archivo incluye la fecha.
Fuera del alcance: Exportaciones programadas, entrega por correo electrónico, formato Excel.
Suposiciones: El número máximo de filas es inferior a 10k; no hay PII en los campos exportados.

AC-001: La exportación genera un archivo con los encabezados correctos
- Escenario: usuario autenticado, al menos una fila de datos visible
- Acción: hacer clic en "Exportar CSV"
- Esperado: el navegador descarga un archivo con las columnas [id, nombre, fecha_creación]
- No debe: exponer campos internos ni filas pertenecientes a otros usuarios
- Verificación: prueba de integración automatizada + verificación manual del esquema
- Prioridad: Requerido

Disparador de Informe Completo — "Migrar la autenticación de usuarios a OAuth"

Cambio de autenticación + dependencia externa + datos de sesión existentes → Informe Completo con tabla de Revisión de Riesgos, decisiones bloqueantes sobre la estrategia de invalidación de sesión y AC de reversión explícitos.

Revisión de especificación existente — el usuario pega un PRD

La skill lo revisa para detectar límites de alcance faltantes, requisitos no verificables ("el sistema será rápido") y suposiciones implícitas, y luego devuelve criterios corregidos o complementarios sin reiniciar el descubrimiento.

Reglas Operativas

1. Inspeccionar el repositorio disponible, la documentación, el problema, el diseño y el contexto de pruebas antes de preguntar por hechos técnicos que puedan descubrirse localmente.
2. No inferir restricciones de producto o negocio a partir del código. Las reglas de negocio, las obligaciones de cumplimiento y regulatorias, los SLA contractuales, los precios, la política de retención de datos, la priorización y los usuarios objetivo no pueden leerse de un repositorio. Tratarlos como desconocidos hasta que el usuario los proporcione o un artefacto de producto autorizado (PRD, contrato, documento de política) los indique. Registrarlos como suposiciones marcadas para confirmación, nunca como hechos descubiertos. El repositorio le dice cómo se comporta el sistema hoy, no lo que el negocio requiere que haga.
3. Hacer solo preguntas cuyas respuestas sean necesarias y no puedan inferirse de manera segura. Agrupar preguntas cortas y relacionadas cuando eso ahorre turnos innecesarios.
4. No bloquear la implementación por defecto. Cuando el usuario ha solicitado implementar un cambio suficientemente claro, registrar brevemente las suposiciones clave y los criterios de aceptación, luego proceder o pasarlos al flujo de trabajo de implementación.
5. Requerir confirmación explícita del usuario antes de proceder solo cuando una decisión no resuelta pueda crear una exposición material de seguridad, pérdida de datos, migración irreversible, ruptura contractual/de API, costo significativo o una acción externa destructiva.
6. No escribir un documento de aceptación en un repositorio, alterar archivos del proyecto, crear una rama, hacer un commit ni invocar otra skill a menos que el usuario lo solicite o el flujo de trabajo activo del repositorio lo requiera explícitamente.
7. Tratar las pruebas automatizadas como evidencia, no como verdad. Preferir la automatización cuando sea confiable y proporcionada; permitir la verificación manual de UX, accesibilidad, seguridad, legal u operativa cuando la automatización no pueda establecer el resultado.
8. Nunca incluir secretos reales, credenciales, tokens, claves privadas, datos personales o cargas útiles de producción sensibles en los criterios de aceptación, fixtures, ejemplos o artefactos guardados. Usar valores redactados o sintéticos.
9. No ejecutar pruebas destructivas, migraciones, sondas de seguridad, pruebas de carga, llamadas externas pagadas u operaciones contra datos de producción/en vivo sin autorización explícita y un entorno seguro identificado.
10. Cuando un criterio de aceptación no pueda cumplirse debido a una restricción arquitectónica, de plataforma o externa descubierta durante la implementación, no omitirlo silenciosamente ni buscar una solución alternativa. Actualizar el criterio afectado (marcarlo como [revisado], indicar la restricción y ajustar el alcance o el método de verificación), incrementar el número de revisión y volver a presentar solo los criterios modificados al usuario antes de continuar. Requerir confirmación explícita solo si la revisión cambia una decisión bloqueante o reduce materialmente las garantías de seguridad o corrección.

Elegir la Profundidad

Usar la salida más pequeña y útil.

Captura Rápida

Usar para un cambio claro pero no trivial con riesgo bajo o moderado. Producir:

• Objetivo
• Dentro del alcance / Fuera del alcance
• Suposiciones
• 3-7 criterios de aceptación con métodos de verificación
• Preguntas bloqueantes, si las hay

No retrasar la implementación para aprobación a menos que exista un riesgo bloqueante de las reglas operativas o el usuario haya solicitado específicamente una especificación primero.

Informe de Aceptación Completo

Usar para cambios ambiguos, entre sistemas, sensibles a la seguridad, que modifican datos, de migración, de cumplimiento o de alto costo, o cuando el usuario solicite un artefacto de entrega. Producir la plantilla completa a continuación y solicitar confirmación para decisiones bloqueantes no resueltas antes de la implementación riesgosa.

Revisión de Especificación Existente

Cuando el usuario ya haya proporcionado un PRD, issue, plan o criterios de aceptación:

1. Revisarlo en lugar de reiniciar el descubrimiento.
2. Identificar límites de alcance faltantes, suposiciones inseguras, contradicciones y requisitos no verificables.
3. Devolver criterios corregidos o complementarios.

Flujo de Trabajo

1. Establecer Objetivo y Riesgo

Extraer o preguntar:

• El resultado observable para el usuario o el sistema.
• Los actores afectados.
• La principal consecuencia de fallo.
• Las dimensiones de riesgo que realmente aplican: seguridad/privacidad, datos persistentes, compatibilidad/API, migración, dependencias externas, costo, concurrencia, rendimiento, usabilidad/accesibilidad.

Evitar hacer preguntas genéricas sobre riesgos irrelevantes.

2. Descubrir Contexto

Cuando haya artefactos locales o conectados disponibles, inspeccionar solo lo necesario:

• Comportamiento existente y archivos o interfaces directamente relacionados.
• Convenciones del repositorio, documentación del producto, contratos de API, esquemas de datos o historial de migraciones.
• Infraestructura de verificación existente y comandos realistas.
• Dependencias externas y si se pueden probar de forma aislada.

Registrar los hechos descubiertos por separado de las suposiciones proporcionadas por el usuario. Si no se puede inspeccionar el contexto, indicar qué se desconoce y hacer preguntas enfocadas.

El repositorio revela hechos técnicos: cómo se comporta el sistema hoy, sus convenciones y sus contratos. No revela restricciones de producto o negocio: reglas de negocio, obligaciones de cumplimiento y regulatorias, SLA contractuales, precios, política de retención de datos, priorización y usuarios objetivo. Nunca reconstruir estos a partir del código o los nombres. Capturarlos solo del usuario o de un artefacto de producto autorizado, y enumerarlos como suposiciones a confirmar hasta entonces.

3. Definir el Alcance

Indicar:

• Objetivo: una oración que describa el resultado previsto.
• Dentro del alcance: comportamiento que este cambio debe entregar.
• Fuera del alcance: trabajo adyacente tentador excluido explícitamente.
• Suposiciones: afirmaciones aún no probadas.
• Decisiones bloqueantes: opciones no resueltas que afectan materialmente la seguridad o el comportamiento.

4. Redactar Criterios de Aceptación

Usar AC-001, AC-002, etc. Cada criterio debe describir un comportamiento observable y un método de verificación apropiado; no es necesario que los criterios y las pruebas tengan una correspondencia uno a uno.

Para cada criterio aplicable incluir:

• Escenario o condición inicial.
• Acción o desencadenante.
• Comportamiento observable esperado.
• Efecto secundario prohibido cuando sea significativo.
• Método de verificación: prueba automatizada, verificación de integración, revisión UX manual, verificación de accesibilidad, revisión de seguridad, verificación operativa o aceptación de las partes interesadas.
• Restricción de entorno/seguridad cuando la verificación pueda afectar datos, servicios, costos o secretos.
• Prioridad: requerido, importante u opcional.

No usar palabras como "correctamente", "de forma segura", "rápido", "intuitivo" o "robusto" sin definir evidencia observable o registrarlas como un juicio de revisión humana.

5. Cubrir Solo los Límites Relevantes

Considerar estas categorías, pero incluir solo las que apliquen:

Categoría	Incluir cuando	Evidencia típica
Camino feliz	Comportamiento nuevo o modificado visible para el usuario	Flujo exitoso o transición de estado
Validación	El cambio acepta entrada	Rechazo de valor mal formado o límite sin mutación
Autorización/privacidad	Datos o acciones tienen límites de acceso	Acceso denegado y sin divulgación sensible
Persistencia/migración	Datos almacenados o esquemas cambian	Lectura hacia atrás, migración, reversión o comportamiento de copia de seguridad
Compatibilidad	API públicas, archivos, eventos o clientes pueden romperse	El contrato o fixture existente sigue siendo válido
Recuperación de fallos	Existe fallo de red, servicio o asíncrono	Sin estado parcial o comportamiento de reintento/ degradado claro
Idempotencia/concurrencia	Repeticiones o escrituras simultáneas son plausibles	Sin efecto secundario duplicado o estado final inválido
Rendimiento	Un umbral de usuario o servicio es relevante	Condiciones de medición y umbral definidos
UX/accesibilidad	Una persona interactúa con el resultado	Teclado, retroalimentación, recuperación de errores, revisión visual/manual

6. Presentar y Continuar

• Para una solicitud de aclaración/especificación, presentar el informe y solicitar decisiones solo sobre los bloqueadores enumerados.
• Para una solicitud de implementación sin bloqueador, presentar un resumen compacto de criterios como parte del trabajo y continuar con la implementación.
• Para la entrega a otro agente o equipo, incluir suficiente contexto y detalle de verificación para que puedan actuar sin inventar requisitos.
• Guardar el informe en un archivo solo cuando se solicite. Usar una ruta aprobada por el repositorio cuando exista; de lo contrario, preguntar o indicar el destino elegido antes de escribir.

Plantilla de Salida

Usar esta plantilla para un Informe de Aceptación Completo. Omitir secciones irrelevantes para Captura Rápida.

# Informe de Aceptación: <Nombre del Cambio>

**Estado:** Borrador | Aprobado | Implementado | Verificado
**Revisión:** <número>
**Preparado para:** <usuario/equipo/agente, cuando se conozca>
**Aprobación requerida antes de trabajo riesgoso:** Sí | No - <razón>

## Registro de Revisiones

| Rev | Fecha | Criterios modificados | Razón |
| --- | --- | --- | --- |
| 1 | <fecha> | — | Borrador inicial |

## Objetivo

<Una oración de resultado observable.>

## Alcance

**Dentro del alcance**
- <comportamiento incluido>

**Fuera del alcance**
- <trabajo adyacente excluido>

## Contexto

**Hechos descubiertos** (técnicos, verificados del repositorio o artefacto)
- <cómo se comporta el sistema hoy, convenciones, contratos>

**Restricciones de producto/negocio** (proporcionadas por el usuario o artefacto de producto, nunca inferidas del código)
- <regla de negocio, obligación de cumplimiento/SLA, política de retención, prioridad, usuario objetivo — o "ninguna proporcionada aún">

**Suposiciones**
- <afirmación no verificada a confirmar o validar>

**Dependencias y restricciones**
- <servicio externo, convención local, obligación de compatibilidad, límite de entorno>

## Revisión de Riesgos

| Área de riesgo | ¿Aplica? | Manejo requerido |
| --- | --- | --- |
| Seguridad/privacidad | Sí/No | <redacción, autorización, revisión, etc.> |
| Datos persistentes/migración | Sí/No | <compatibilidad, copia de seguridad, reversión, etc.> |
| Efectos externos/costo | Sí/No | <entorno sandbox/prueba/autorización> |
| Compatibilidad/API | Sí/No | <contrato a preservar o versionar> |
| UX/accesibilidad | Sí/No | <evidencia manual o automatizada> |

## Criterios de Aceptación

### AC-001: <comportamiento observable>
- **Escenario:** <condición inicial>
- **Acción:** <desencadenante único>
- **Esperado:** <resultado observable>
- **No debe:** <efecto secundario prohibido, si aplica>
- **Verificación:** <método y evidencia prevista>
- **Entorno/seguridad:** <restricciones, si aplica>
- **Prioridad:** Requerido | Importante | Opcional

## Decisiones Bloqueantes

- [ ] <solo decisiones que impidan el progreso seguro o correcto>

## Plan de Verificación

| Criterio | Evidencia de verificación | Estado |
| --- | --- | --- |
| AC-001 | <comando de prueba/verificación/revisión o tipo de evidencia> | Pendiente |

Ejemplos de Aprobado/No Aprobado

Usar estos para juzgar si la skill realmente produjo un informe verificable, no prosa de planificación.

Un criterio de aceptación no aprobado

AC-001: La exportación funciona correctamente y es segura.

No aprobado — "funciona correctamente" y "segura" no son observables, no hay escenario, desencadenante, resultado esperado, efectos secundarios prohibidos ni método de verificación.

Un criterio de aceptación aprobado

AC-001: Exportar CSV descarga un archivo con las columnas esperadas
- Escenario: panel de dashboard con al menos una fila de datos visible para el usuario autenticado
- Acción: hacer clic en el botón "Exportar CSV"
- Esperado: el navegador descarga un archivo CSV que contiene las mismas filas mostradas actualmente
- No debe: exponer filas de otros usuarios, columnas internas ni datos de identificación personal
- Verificación: prueba de integración automatizada que ejecuta la exportación y compara encabezados + recuento de filas, más verificación manual puntual de la muestra
- Prioridad: Requerido