brainstorming

name	brainstorming
description	Facilita la definición de requisitos antes de implementar. Hace preguntas para eliminar ambigüedades, enfocándose en el qué y el cómo (no en detalles técnicos), y presenta 2-3 enfoques para resolver el problema. Usar al iniciar features nuevas, cambios de diseño, o cuando la petición del usuario sea vaga o ambigua.

Brainstorming

Objetivo

Aclarar qué se quiere lograr y cómo debería funcionar desde la perspectiva del usuario o del negocio. No entrar en detalles técnicos (archivos, stack, APIs, arquitectura).

Este skill termina con 2-3 enfoques posibles y una recomendación. La implementación y el plan técnico vienen después.

Cuándo usar

Siempre. Es la fase ① del flujo obligatorio en AGENTS.md. Aplica a toda tarea, sin excepciones.

En tareas pequeñas, el brainstorming puede ser breve (reformular + 1–2 preguntas + enfoque recomendado), pero no se omite.

Flujo

1. Entender la petición inicial

Reformular en 1-2 frases lo que entendiste. Si hay suposiciones, marcarlas explícitamente.

2. Hacer preguntas para eliminar ambigüedad

Priorizar preguntas sobre qué y cómo, no sobre tecnología.

Dimensión	Ejemplos de preguntas
Problema	¿Qué dolor resuelve? ¿Quién lo usa?
Alcance	¿Qué entra y qué queda fuera?
Comportamiento	¿Qué pasa en el caso feliz? ¿Y si falla o falta info?
Criterios de éxito	¿Cómo sabemos que está bien?
Restricciones	¿Hay reglas de negocio, plazos o dependencias?
Prioridad	¿Qué es imprescindible vs. nice-to-have?

Reglas:

• Máximo 3-5 preguntas por ronda; no abrumar
• Una pregunta = un tema; evitar preguntas compuestas
• Si la respuesta abre nueva ambigüedad, hacer otra ronda breve
• Parar cuando el qué, el cómo y los criterios de éxito estén claros

Evitar preguntas del tipo: "¿Usamos Redis o memoria?", "¿En qué archivo lo ponemos?", "¿REST o GraphQL?"

3. Sintetizar requisitos acordados

Resumir en bullets:

• Objetivo
• Comportamiento esperado (casos principales)
• Fuera de alcance
• Criterios de aceptación (verificables, sin jerga técnica)

Pedir confirmación explícita antes de proponer enfoques.

4. Presentar 2-3 enfoques

Para cada enfoque incluir:

### Enfoque [N]: [nombre corto]

**Qué resuelve:** ...
**Cómo funciona:** ... (flujo o experiencia, no implementación)
**Pros:** ...
**Contras:** ...
**Cuándo elegirlo:** ...

Comparar enfoques en una tabla breve si ayuda a decidir.

Terminar con recomendación (un enfoque y por qué), alineada con simplicidad salvo que el usuario indique otra prioridad.

Formato de salida final

## Resumen

[1-2 frases del objetivo acordado]

## Requisitos

- ...
- Criterio de aceptación: ...

## Fuera de alcance

- ...

## Enfoques

### Enfoque 1: ...
...

### Enfoque 2: ...
...

### Enfoque 3: ... (opcional)
...

## Recomendación

[Enfoque elegido y razón en 2-3 frases]

## Siguiente paso

[Spec corta / aprobación del usuario / plan técnico — según el flujo del proyecto]

Ejemplo breve

Petición: "Quiero que el agente recuerde conversaciones anteriores."

Preguntas (qué/cómo):

• ¿El usuario debe ver el historial completo o solo contexto relevante?
• ¿Cuánto tiempo debe persistir (sesión, días, siempre)?
• ¿Qué pasa si el usuario pide olvidar algo?

Enfoques (sin detalle técnico):

1. Solo contexto reciente — el agente "recuerda" lo último de la sesión; simple, sin historial visible.
2. Historial por usuario — el usuario puede retomar conversaciones pasadas; más útil, más complejidad de producto.
3. Resumen automático — no guarda todo el chat, sino un resumen de temas abiertos; balance entre memoria y privacidad.

Recomendación: Enfoque 1 si el MVP es rápido; Enfoque 3 si hay preocupación por privacidad y costo.

Anti-patrones

• Saltar directo a código o arquitectura
• Proponer un solo enfoque sin alternativas
• Preguntas técnicas antes de entender el problema
• Specs largas; mantenerlo conciso y accionable
• Asumir requisitos no confirmados por el usuario