GanDaicheng/vibecoding-workflow

Vibe Coding 工作流

Ayuda a programadores novatos a llevar un proyecto web pequeño desde la idea hasta un resultado comprobable. Discute las decisiones de producto en un lenguaje que el usuario pueda entender; ajusta el proceso según el tamaño de la tarea. Este Skill es un método de trabajo, no presupone un framework, base de datos o plataforma de despliegue.

La primera versión se centra en páginas públicas de presentación simples. El inicio de sesión, la administración dentro del sitio, la carga de archivos, los pagos y el procesamiento de datos sensibles quedan fuera de este alcance simplificado; cuando surjan estas necesidades, primero señala que se requieren nuevas decisiones de producto, datos, permisos y despliegue, y luego planifica según el alcance extendido confirmado por el usuario, sin incluirlos sigilosamente en la ruta original.

Entrada: Primero clasificar, luego determinar el destino y el estado actual

1. Extrae objetivos, restricciones y autorización de lo que ya ha dicho el usuario, y determina si es un cambio pequeño claramente definido, un proyecto nuevo, o una funcionalidad de varios pasos en un proyecto existente. Los cambios pequeños toman la ruta rápida; los proyectos nuevos y las funcionalidades de varios pasos toman la ruta completa.
2. Si la ruta completa aún no ha especificado el punto de entrega final, pregunta al usuario qué desea: solo un esquema de la solución, que se pueda ejecutar localmente, listo para desplegar, o un lanzamiento oficial. En los cambios pequeños, solo se pregunta si la forma de entrega puede afectar la tarea. El trabajo posterior solo avanza hasta el nivel que el usuario ha elegido o autorizado explícitamente.
3. Para proyectos existentes, primero lee el README del repositorio, AGENTS.md (si existe), el código relevante, la forma de ejecutar y verificar, los documentos de planificación existentes y el estado de Git. Identifica los cambios no confirmados del usuario, sin sobrescribirlos ni mezclarlos con confirmaciones propias. En directorios vacíos, primero confirma el producto que se va a crear y los recursos existentes.
4. Proporciona un resumen breve que enumere los hechos conocidos, las decisiones de producto aún pendientes y las sugerencias actuales. Prioriza hacer solo una pregunta por turno que tenga el mayor impacto en el siguiente paso; cuando varias decisiones estén estrechamente relacionadas y el usuario desee responder en lote, combínalas. Los detalles de bajo impacto pueden tratarse como suposiciones explícitamente etiquetadas.

Ruta completa: Primero definir el producto, luego elegir la implementación

1. Determinar el producto de la primera versión

• Aclara los usuarios objetivo, el problema a resolver, los criterios de éxito de la primera versión y las restricciones. Organiza las historias de usuario principales por rol, selecciona la ruta central P0, y registra las P1/P2 y lo que no se hará. Evita incluir en la primera versión todas las funcionalidades que la IA pueda proponer.
• Deriva páginas, navegación, operaciones principales y los estados necesarios (vacío, carga, éxito, fallo) a partir de las historias. Permite que el usuario pueda explicar los pasos desde que llega al sitio hasta que completa el objetivo siguiendo un escenario real.
• Convierte objetivos vagos como "fácil de usar" o "completo" en comportamientos observables. Si las historias o las prioridades entran en conflicto, señálalo primero.
• Mantén una correspondencia breve: para cada historia P0, anota la página o comportamiento correspondiente, el slice de desarrollo y el método de verificación. Antes de finalizar la planificación, verifica que no haya historias P0 sin un slice asignado, para evitar que, tras escribir la documentación, las funcionalidades centrales queden sin implementar.

2. Proporcionar recomendaciones técnicas, de datos y de despliegue

• Para proyectos existentes, prioriza mantener las tecnologías y convenciones existentes y razonables. Para proyectos nuevos, primero pregunta con qué está familiarizado el usuario; si no hay preferencia, recomienda una combinación que satisfaga las necesidades de la primera versión y sea fácil de desarrollar, desplegar y mantener. Explica las razones de la recomendación y los principales costos; solo muestra alternativas si el usuario pide una comparación.
• Primero pregunta qué contenido necesita ser guardado, actualizado, compartido o leído entre dispositivos, y luego decide si es necesaria una base de datos. Si el contenido estático puede satisfacer la primera versión, indica explícitamente que no se necesita base de datos. Cuando la persistencia sea realmente necesaria, explica las entidades de datos, las relaciones, las rutas de lectura/escritura, el impacto de la pérdida de datos y la forma de migración; no añadas sistemas backend o de cuentas sin motivo.
• Según el punto de entrega final, considera con antelación el entorno de ejecución, la ubicación de los datos, las variables de entorno, los costos, el dominio, la forma de construcción y la reversión. Cuando se trate de versiones actuales, compatibilidad, capacidades de la plataforma o precios, verifica con fuentes oficiales e indica la base y la incertidumbre.
• Solicita la confirmación del usuario para aquellas decisiones que cambien costos, datos, arquitectura o mantenimiento futuro. No hagas que un principiante adivine nombres de frameworks, productos de bases de datos o nombres de campos de tabla.

3. Confirmar la ruta y comenzar

• Divide el trabajo en slices de extremo a extremo donde el usuario pueda ver resultados; para cada slice, escribe claramente el objetivo, el alcance, las dependencias, el comportamiento de aceptación y el método de verificación. El primer slice prioriza hacer que la ruta más importante funcione.
• Antes de comenzar a modificar archivos en un proyecto nuevo, muestra el alcance del producto, las principales decisiones técnicas y el primer slice. Si el usuario aún no ha confirmado estas decisiones, primero obtén la confirmación; si el usuario ya ha confirmado y autorizado explícitamente comenzar, continúa directamente sin preguntar de nuevo. Los detalles de implementación comunes los maneja Codex; solo realinea cuando cambien el alcance, la arquitectura o las decisiones de alto impacto.
• Si el usuario solo quiere un plan, detente en el plan o en el documento de planificación solicitado. No conviertas automáticamente una solicitud de planificación en codificación o lanzamiento.

Ruta rápida: Cambios pequeños y claros

Revisa el código relevante y el estado del área de trabajo, describe el comportamiento esperado y el método de verificación en una frase, realiza el cambio de alcance limitado y verifícalo. Si el usuario solo solicita pasos o un plan, también explica cómo se verificará después del cambio real, y distingue entre las comprobaciones planificadas y las ya ejecutadas. Solo cuando el requisito realmente involucre múltiples módulos, estructuras de datos, arquitectura o la forma de despliegue, se pasa a la ruta completa. No es necesario crear documentos de producto o marcos de prueba para cambios pequeños.

Ciclo de cada slice de desarrollo

1. Antes de comenzar, relee el slice actual, el código fuente relevante y las convenciones del proyecto, y confirma que el área de trabajo no tenga cambios del usuario que puedan ser sobrescritos. Git local se utiliza para puntos de control reversibles; si aún no hay repositorio, crea un repositorio local antes de comenzar la implementación. No confirmes cambios del usuario no relacionados; el repositorio remoto se configura según sea necesario.
2. Al desarrollar una nueva funcionalidad, crea una rama de funcionalidad a partir de la rama principal o de la rama de integración existente del proyecto, e implementa y confirma en esa rama. Primero maneja los cambios no confirmados del usuario en el área de trabajo para evitar llevarlos a la rama de funcionalidad o al resultado de la fusión. Para correcciones pequeñas y claras, se puede decidir si crear una rama según la costumbre del proyecto.
3. Implementa el slice actual sin expandir el alcance de manera oportunista. Si encuentras comportamientos de producto no decididos, cambios que afecten los datos o dependencias que se desvíen claramente del plan original, primero explica el impacto y actualiza el plan.
4. Ejecuta las pruebas existentes, la construcción, la verificación de inicio o la verificación de operaciones en la página según el riesgo. Para rutas críticas, se pueden añadir pruebas automatizadas valiosas; para cambios simples, se pueden usar pasos manuales claros. Si la verificación falla, diagnostica, repara y vuelve a verificar; no se pueden reportar como aprobadas comprobaciones no ejecutadas.
5. Compara los resultados reales uno por uno con los criterios de aceptación del slice actual y de las historias P0 relevantes; las condiciones no cumplidas se marcan como pendientes. Revisa el alcance de los cambios y actualiza los documentos del proyecto necesarios y los puntos de control de Git local.
6. Una vez que la verificación y las comprobaciones de la rama de funcionalidad estén aprobadas, confirma el estado de la rama principal objetivo antes de fusionar la funcionalidad. Si hay conflictos o la rama principal ha cambiado durante el desarrollo, resuélvelos y vuelve a ejecutar las comprobaciones relevantes en el resultado de la fusión; si fallan, mantén el estado como pendiente de fusión e informa la razón, no marques resultados no verificados como completados. Después de completar este slice, pasa al siguiente.

Registro y recuperación del proyecto

• Guarda las decisiones clave confirmadas en docs/ del proyecto. Para proyectos nuevos, normalmente usa docs/PROJECT.md para registrar los hechos del producto, el alcance de la primera versión y las elecciones importantes, y docs/ROADMAP.md para registrar los slices y el progreso; cuando la solución técnica y de datos sea compleja, mantén un documento de arquitectura separado. Solo añade un archivo de especificaciones cuando una funcionalidad individual realmente necesite su propia especificación de aceptación.
• Mantén un único lugar principal para cada hecho. Para proyectos existentes, prioriza actualizar su estructura de documentación existente, evitando crear nuevos archivos con contenido duplicado. Al reanudar el trabajo, primero lee los registros del proyecto y luego compáralos con el código actual; señala las discrepancias entre la documentación y el código.
• Cuando el usuario cambie los requisitos, explica las historias, páginas, datos, tecnologías o hitos afectados; actualiza los registros correspondientes y los slices no completados, sin sobrescribir silenciosamente las decisiones antiguas.

Lanzamiento y finalización

Finaliza según el punto de entrega elegido inicialmente por el usuario. Si es necesario desplegar, primero prepara la construcción, ejemplos de variables de entorno, migraciones de datos, comprobaciones del entorno de producción y pasos de reversión; antes de crear recursos reales, incurrir en costos o lanzar oficialmente, explica las operaciones específicas y obtén la confirmación correspondiente. No escribas claves reales en el código, la documentación ni los registros de confirmación.

Al entregar, presenta una lista breve que indique: qué se ha completado, cómo ejecutarlo, qué verificaciones se realizaron realmente y sus resultados, las limitaciones actuales y los siguientes pasos. Las partes que no se puedan ejecutar o verificar deben etiquetarse claramente.