Nuevas Funcionalidades, Corrección de Bugs, Cierres: Superpowers en Flujos de Trabajo del Mundo Real

Escribir código parece "modificar archivos" en la superficie, pero en la práctica es principalmente: descubrir primero qué hacer, luego actuar, luego probar que no se rompió, luego entregarlo. Superpowers tiene muchos skills que pueden sonar como mucho para seguir — pero en el trabajo real, piénsalo como una hoja de trucos para "cuando me encuentro con esta situación, qué llamo primero." Este artículo no re-explica todos los artículos anteriores en su totalidad — solo mapea los cuatro escenarios más comunes en secuencias listas para copiar y pegar. Al final, sabrás al menos: qué flujo de trabajo activar ahora mismo, en lugar de dejar que el agente se lance en el momento en que abres una conversación.

Escenario 1: Construir una Nueva Funcionalidad

Paso 1: using-superpowers.
No es un ritual supersticioso — pone al agente en modo "leer los skills primero, secuenciar los flujos de trabajo primero," para que no empiece a modificar diez archivos en el momento en que abres la boca.

Paso 2: Requisitos todavía en la niebla → brainstorming.
Siempre que tengas un pensamiento como "no estoy realmente seguro de cuál es el mejor enfoque," espera en la implementación. Descubre la intención, las restricciones y los trade-offs — convierte las opciones en opción múltiple en lugar de adivinanzas.

Paso 3: El alcance crece, los pasos se multiplican → writing-plans (o el flujo de trabajo equivalente "escribir el plan antes de actuar" de tu entorno).
Planificar antes de implementar, y el retrabajo cae drásticamente. El artículo spec/plan/implementation de esta serie profundiza más en esto — por ahora, solo recuerda: funcionalidad grande = escribe el mapa de ruta primero.

Paso 4: Listo para tocar código → implementar según el plan; si tu equipo prefiere test-first, combina con test-driven-development.
El punto no es memorizar el nombre — es "definir primero cómo se ve lo correcto, luego codificar hasta que sea correcto."

Mnemotécnico: Nueva funcionalidad = activar hábitos primero → alinear requisitos → planificar trabajo grande primero → luego implementar y verificar.

Escenario 2: Corregir un Bug

Paso 1: Todavía using-superpowers.
Llegar a la mitad de una corrección de bug solo para darse cuenta de que "estábamos corrigiendo el campo de batalla equivocado" es extremadamente común. Abrir con el flujo de trabajo mantiene tu mentalidad estable.

Paso 2: systematic-debugging.
Reemplaza "adivinar" con "eliminación basada en evidencia": pasos de reproducción, observar el fenómeno, reducir el alcance, validar la hipótesis. Lo que más comúnmente les falta a los principiantes no es inteligencia — es una pregunta más: "¿cómo sé que aquí es donde está roto?"

Paso 3: Causa raíz encontrada, antes de escribir código — si el cambio podría tocar múltiples áreas → vuelve a un plan corto o al menos lista el radio de explosión.
Las correcciones pequeñas pueden ser breves, pero siempre que tu instinto diga "¿y si esto rompe algo más," escribe dos líneas de notas de trade-off antes de actuar.

Paso 4: Cambio completo → el tipo de hábito de verificación verification-before-completion.
Ejecuta los comandos que necesitan ejecutarse, revisa la salida que necesita revisarse, luego di "terminado." Esto es mucho más agradable que ser etiquetado por un compañero de equipo a medianoche.

Mnemotécnico: Corrección de bug = using-superpowers para abrir → debugging sistemático → pensar en el impacto antes de cambiar → verificar antes de decir que está terminado.

Escenario 3: Responder a una Revisión de Código

¿Por qué el paso 1 aquí dice receiving-code-review en lugar de using-superpowers como los dos primeros escenarios? Respuesta sencilla: si tú y el agente ya están en el mismo contexto de tarea (por ejemplo, acabas de terminar de implementar y ahora estás procesando comentarios de PR), responder a una revisión es naturalmente "el siguiente paso en un flujo de trabajo existente" — llamar a receiving-code-review directamente es lo más apropiado. Por el contrario, las nuevas funcionalidades y las correcciones de bugs frecuentemente entran desde una pizarra en blanco, y necesitan using-superpowers primero para activar el hábito "seguir el flujo de trabajo." Si estás comenzando una conversación completamente nueva, o cambiando a un contexto completamente nuevo y te sientes inseguro, todavía puedes hacer using-superpowers primero para confirmar qué skill aplica, luego entrar en receiving-code-review. Los dos enfoques no entran en conflicto — la diferencia está en dónde en el flujo de trabajo estás parado cuando entras.

Paso 1: receiving-code-review.
El espíritu de este skill: primero entender qué está diciendo el feedback, qué elementos deben cambiar y cuáles necesitan discusión — no oscilar inmediatamente entre "okay lo cambiaré todo" y "no me entiendes."

Paso 2: Necesitas agregar pruebas, cubrir casos extremos, o el cambio crece → usa un plan o lista de verificación para desglosar "tareas de esta revisión."
Trata los comentarios de revisión como mini-requisitos: cada comentario corresponde a un resultado verificable.

Paso 3: Después de los cambios, verifica → el hábito de "necesitar evidencia antes de terminado" también aplica aquí.
Responder a una revisión no es solo modificar código — incluye poder decir "así es como sé que no hay regresión."

Mnemotécnico: Revisión = leer y categorizar primero → tratar como tareas para desglosar → cerrar con verificación.

Escenario 4: Cierre y Entrega

Paso 1: verification-before-completion.
Antes de hacer merge, lanzar o enviar un PR — primero recorre tus verificaciones comprometidas: pruebas, lint, recorrido manual del camino feliz — evidencia antes de declaraciones.

Paso 2: Si el cambio es grande o involucra a múltiples personas → requesting-code-review (o pide a otro agente / compañero de equipo que haga una revisión estructurada).
El objetivo no es encontrar defectos — es atrapar una ronda más de puntos ciegos antes de hacer merge en la línea principal.

Paso 3: Cómo converger el trabajo en la rama → el tipo de hábito de "decisión de cierre" de finishing-a-development-branch.
Hacer merge, abrir un PR, o limpiar WIP — elige un camino claro. No dejes que las ramas se conviertan en sitios de excavación arqueológica.

Mnemotécnico: Entrega = verificar primero → solicitar una revisión cuando sea necesario → luego converger la rama de forma clara.

Playbook Mínimo Viable para Principiantes

Si tu cerebro solo puede retener un conjunto ahora mismo, recuerda estas cinco palabras en orden: Activar → Aclarar → Planificar → Construir → Probar.

Activar: using-superpowers — pone al agente en modo "sabe cómo usar skills."
Aclarar: Incierto de qué construir → brainstorming; incierto de qué está roto → systematic-debugging.
Planificar: Las tareas grandes obtienen un plan primero (track writing-plans).
Construir: Luego implementar; si test-first está disponible, usa el hábito TDD como guía.
Probar: Antes de decir que está terminado, ejecuta una ronda con el ritmo verification-before-completion; agrega flujos de trabajo de revisión / cierre antes de entregar.

Esta no es la única respuesta correcta, pero para principiantes, los errores más costosos generalmente son de orden incorrecto: escribir código cuando deberías estar aclarando, debatir cuando deberías estar verificando. Establece primero el orden — y la eficiencia mejorará de forma extraña.

Próximos Pasos

Para completar el flujo de trabajo de aterrizaje con spec, plan, implementation: ¿Cuál Es la Diferencia Entre spec, plan e implementation? El Flujo de Trabajo Correcto para Superpowers.
Para entender por qué hacer brainstorming antes de construir importa: using-superpowers y brainstorming: Por Qué No Puedes Saltarte el Diseño y Saltar Directamente a Construir.
Para ver todo el camino y mapa de la serie de un vistazo: Curso para Principiantes de Superpowers.

Volver al Índice de la Serie

Este artículo cubre los cuatro escenarios más comunes del mundo real y el orden de skills recomendado para cada uno. Para volver al mapa de lectura de la serie, el orden recomendado y otros temas de artículos, abre el Curso para Principiantes de Superpowers.