brainstorming

Visión general del skill brainstorming

Para qué sirve el skill brainstorming

El skill brainstorming es un flujo de trabajo estructurado previo a la implementación para convertir una idea difusa en un diseño aprobado antes de escribir código. Su función principal no es “generar ideas” en abstracto, sino reducir retrabajo obligando a hacer explícitos el alcance, las suposiciones, los requisitos y las decisiones de diseño desde el principio.

Quién debería instalar este skill brainstorming

Este skill brainstorming encaja mejor con personas o equipos que suelen pasar demasiado rápido de “deberíamos construir X” a implementarlo. Resulta especialmente útil para:

• planificación de funcionalidades
• diseño de componentes
• cambios de comportamiento
• propuestas de herramientas internas
• brainstorming para Requirements Planning

Si ya tienes un proceso disciplinado de especificaciones, este skill puede seguir aportando valor como una capa ligera de entrada a ese proceso.

Qué lo diferencia de un prompt normal

La diferencia clave es la barrera estricta definida en SKILL.md: el agente no debe implementar, crear scaffolding ni escribir código hasta haber presentado un diseño y recibido aprobación. Suena simple, pero cambia de forma material el comportamiento frente al típico prompt de “ayúdame a construir esto”, donde los asistentes suelen saltar directamente a la solución.

Lo que de verdad suele importar antes de instalarlo

La mayoría de usuarios quiere resolver tres dudas rápido:

1. ¿Me va a hacer ir más lento?
2. ¿Va a hacer preguntas útiles en vez de preguntas genéricas?
3. ¿Puede ayudar con discusiones de diseño visual?

La respuesta es: añade sobrecarga de proceso a propósito, pero esa sobrecarga es pequeña cuando la idea también lo es. El skill defiende explícitamente que incluso el trabajo “simple” necesita una pasada corta de diseño, porque ahí es donde las suposiciones ocultas terminan causando errores caros.

Cómo usar el skill brainstorming

Instalación y configuración de brainstorming

Para añadir el skill desde el repositorio, usa:
npx skills add https://github.com/obra/superpowers --skill brainstorming

Después de instalarlo, abre primero estos archivos:

• skills/brainstorming/SKILL.md
• skills/brainstorming/visual-companion.md
• skills/brainstorming/spec-document-reviewer-prompt.md

Si prevés exploración visual, revisa también:

• skills/brainstorming/scripts/start-server.sh
• skills/brainstorming/scripts/frame-template.html

El flujo central que espera el skill brainstorming

El patrón de uso de brainstorming es deliberadamente guiado:

1. explorar el contexto del proyecto
2. ofrecer opcionalmente el companion visual
3. hacer preguntas de aclaración de una en una
4. sintetizar el diseño
5. obtener aprobación explícita
6. solo entonces pasar a planificación o implementación

Si tu agente salta de la idea al código, en realidad no está siguiendo este skill.

Qué información dar para sacar mejor partido a brainstorming

El skill funciona mucho mejor si le das algo más que el título de una funcionalidad. Un buen punto de partida suele incluir:

• el problema que hay que resolver
• quién es el usuario
• el contexto actual del sistema o del repo
• restricciones
• cómo se ve el “hecho”
• no objetivos conocidos

Una entrada débil:

Add notifications.

Una entrada más sólida:

Add in-app notifications for failed background imports. Users are operations staff, not end customers. We already have email alerts, but they are too slow for live triage. Keep scope to the admin dashboard only. Do not add mobile push or user preference management in v1.

Esa segunda versión da al skill brainstorming suficiente estructura para hacer preguntas de seguimiento mucho más precisas.

Cómo convertir una idea vaga en un primer prompt sólido para brainstorming

Una plantilla práctica de prompt para brainstorming:

Use the brainstorming skill for Requirements Planning.
Context: [project/repo/product]
Problem: [what is happening now]
Target user: [who is affected]
Constraints: [timeline, stack, compliance, UX, compatibility]
Non-goals: [what not to solve]
Please ask clarifying questions one at a time, then present a proposed design for approval before any implementation.

Esto se alinea con el flujo previsto por el skill y reduce la probabilidad de recibir preguntas genéricas.

Cómo deberían funcionar las preguntas de aclaración

Hay un comportamiento sutil pero importante: el skill espera preguntas de una en una, no un cuestionario enorme de descubrimiento. Esto importa porque las respuestas suelen cambiar la siguiente pregunta. Si tu agente vuelca 15 preguntas de golpe, pierdes el refinamiento interactivo que esta guía de brainstorming está pensada para producir.

Cuándo conviene usar el companion visual

El repositorio incluye un companion visual basado en navegador. Úsalo cuando al usuario le resulte más fácil entender las opciones viéndolas:

• wireframes
• comparaciones de layout
• flujos de interfaz
• diagramas de arquitectura
• visuales de estado o relaciones

No lo uses solo porque el tema mencione UI. Una pregunta conceptual como “should this be a wizard or a modal?” puede resolverse en texto. Una pregunta como “which of these two wizard layouts is clearer?” sí encaja claramente con la vía visual.

Cómo se sirve realmente el companion visual

La ayuda visual no es solo documentación; hay scripts para ejecutar una sesión local:

• scripts/start-server.sh
• scripts/stop-server.sh
• scripts/server.cjs
• scripts/helper.js

start-server.sh levanta un servidor local en un puerto alto aleatorio y puede guardar archivos de sesión tanto en /tmp como dentro de un directorio del proyecto, por ejemplo .superpowers/brainstorm/. Esto es útil si quieres que los mockups persistan entre sesiones.

Notas prácticas del entorno antes de depender de lo visual

El flujo visual asume un entorno accesible desde navegador. Si trabajas en un contenedor remoto, una VM o por SSH, presta atención a:

• --host
• --url-host
• persistencia del directorio de sesión

Para uso puramente local, los valores por defecto son sencillos. En entornos compartidos o remotos, conviene resolver los detalles de red antes de montar el flujo alrededor del feedback en navegador.

La mejor ruta de lectura de archivos para adoptarlo rápido

Si quieres la ruta más corta hacia un uso de calidad real, lee en este orden:

1. SKILL.md para entender el contrato de comportamiento
2. visual-companion.md para saber cuándo ayuda el soporte en navegador
3. spec-document-reviewer-prompt.md para ver qué significa “suficientemente bueno para implementar”
4. scripts/start-server.sh si necesitas la vía visual

Así obtienes primero la lógica de decisión y luego el tooling opcional.

Qué aspecto debería tener una buena salida de brainstorming

Una sesión de brainstorming bien resuelta debería terminar con un diseño lo bastante concreto como para revisarlo, incluyendo:

• objetivo y usuario
• límites de alcance
• decisiones clave
• riesgos o suposiciones abiertas
• suficiente especificidad como para planificar la implementación

Si la salida se queda en una lista suelta de ideas, la sesión se cortó demasiado pronto.

Cómo usar brainstorming para Requirements Planning

Para brainstorming para Requirements Planning, usa el skill como paso previo a la spec:

1. aclarar el problema y las restricciones
2. bosquejar el diseño o la forma de los requisitos
3. obtener aprobación
4. escribir la spec
5. ejecutar la plantilla de prompt del reviewer de spec si hace falta

Es uno de los usos más sólidos del skill porque detecta deriva de alcance y ambigüedad antes de que la planificación quede fijada.

Preguntas frecuentes sobre el skill brainstorming

¿El skill brainstorming es solo para proyectos grandes?

No. El skill rechaza explícitamente la idea de que el trabajo “pequeño” pueda saltarse el diseño. En un cambio mínimo, el diseño esperado puede ser breve, pero ese paso sigue importando. De hecho, el valor suele ser mayor en cambios supuestamente simples, donde las suposiciones rara vez se ponen a prueba.

¿Es mejor que los prompts normales de brainstorming?

Por lo general, sí, si tu objetivo real es llegar a claridad lista para ejecutar y no simplemente a volumen de ideas. Un prompt normal de brainstorming puede generar muchas opciones. Este skill brainstorming funciona mejor cuando necesitas pensamiento convergente: entender el contexto, acotar opciones y producir un diseño aprobado.

¿El skill brainstorming es apto para principiantes?

Sí, especialmente para personas que construyen en solitario y todavía no tienen hábito de planificación. La estructura compensa un error muy común de principiantes: implementar la primera idea plausible sin aclarar antes requisitos ni tradeoffs.

¿Cuándo encaja mal brainstorming?

Conviene omitirlo o acortarlo cuando:

• la tarea es puramente mecánica y ya está totalmente especificada
• no estás tomando una decisión de diseño o de comportamiento
• el usuario ya aprobó una spec detallada y solo necesita ejecución

Aun así, verifica que la barrera estricta no choque con tu flujo. Este skill es intencionalmente exigente.

¿Este skill genera código?

No, y es deliberado. El skill brainstorming debe detenerse antes de la implementación hasta que exista aprobación. Si quieres generación de código, usa primero este skill y, después de aprobar el diseño, pásalo a un skill de planificación o implementación.

¿Necesito el companion visual para obtener valor?

No. La vía en navegador es opcional. El uso de brainstorming solo en texto sigue aportando la mayor parte del valor en conversaciones sobre requisitos, alcance y tradeoffs técnicos. Las herramientas visuales importan más cuando la decisión en sí es visual.

Cómo mejorar el skill brainstorming

Dale al skill brainstorming más contexto real del proyecto

La forma más rápida de mejorar resultados es anclar la conversación en la realidad:

• archivos o carpetas relevantes
• comportamiento existente
• cambios recientes
• restricciones técnicas conocidas
• usuarios afectados

El propio skill indica al agente que primero explore el contexto del proyecto. Ayúdale señalando dónde vive ese contexto.

Declara pronto las restricciones y los no objetivos

Muchas salidas flojas de brainstorming vienen de límites poco definidos. Dile al skill qué debe preservar o evitar:

• compatibilidad hacia atrás
• límites de rendimiento
• requisitos de compliance o seguridad
• límites de tiempo o de equipo
• funcionalidades explícitamente fuera de alcance

Esto produce diseños más acotados y más útiles para decidir.

Pide un diseño, no solo ideas

Si quieres una salida lista para implementar, dilo de forma explícita. Pide al skill brainstorming que termine con:

• un diseño propuesto
• suposiciones
• preguntas sin resolver
• un punto de control de aprobación explícito

Eso orienta la sesión lejos de la ideación infinita y hacia un artefacto utilizable.

Usa prompts más sólidos para brainstorming visual

Para trabajo visual, no digas solo “show mockups.” Especifica qué debe comparar la parte visual:

Show two dashboard layout options for failed import alerts: one optimized for fast triage, one optimized for detail review. Keep the existing navigation shell. Highlight which option better supports keyboard-heavy operators.

Ese tipo de prompt ayuda al companion visual a generar salidas orientadas a decidir, no pantallas decorativas.

Vigila el principal modo de fallo: ir demasiado pronto a la solución

El fallo más común es saltar a detalles de implementación antes de entender realmente el problema. Si ocurre, redirige la sesión:

Pause implementation thinking. What assumptions are we making about the user workflow, edge cases, and scope boundaries?

Eso mantiene la guía de brainstorming alineada con su propósito central.

Mejora la primera salida con una pasada de revisión

Después del diseño inicial, pide una revisión enfocada en lugar de reiniciar desde cero:

• ¿qué es ambiguo?
• ¿qué está sobrediseñado?
• ¿qué rompería la planificación de la implementación?
• ¿qué falta para aprobarlo?

El spec-document-reviewer-prompt.md del repositorio es útil aquí porque calibra la revisión alrededor de bloqueadores reales de planificación, no de retoques cosméticos.

Mantén el artefacto de brainstorming pequeño pero completo para decidir

Un error habitual es inflar el diseño con detalle innecesario. Mejor brainstorming no significa brainstorming más largo. Para trabajo simple, pueden bastar unos pocos párrafos ajustados que cubran propósito, alcance, restricciones, enfoque y aprobación. El estándar no es la longitud del documento, sino si el siguiente paso puede avanzar con menos suposiciones.

Combina brainstorming con una revisión de spec

Si adoptas este skill en serio, combínalo con una revisión posterior de la spec o del diseño producido. La plantilla de reviewer incluida comprueba:

• placeholders
• contradicciones
• requisitos ambiguos
• alcance excesivamente amplio
• complejidad no solicitada

Eso hace que el skill brainstorming sea más útil en un flujo real de entrega, no solo dentro del chat.