Cómo llevo el software a producción
Cada proyecto que asumo recorre el mismo ciclo: un problema real se convierte en una incidencia revisada, en una especificación acordada, en una implementación con estándares, en una compilación verificada en staging y, solo entonces, en una publicación deliberada. Este es ese ciclo, paso a paso.
Paso 1 — Problema
Un problema real, en palabras del negocio
Empieza como una queja, no como un ticket: ese trabajo de última milla que nunca recibe presupuesto y que, en silencio, le cuesta horas al equipo cada semana. La tarea es escucharlo con la precisión suficiente para acotarlo.
Lo que el agente ejecuta aquí
superpowers:brainstormingExplora la intención, las restricciones y los criterios de éxito antes de que exista código: el diseño se acuerda, no se supone.
Cómo leer esto
Comando — un comando que ejecuto yo mismo
Skill de plugin — habilidades de dominio instaladas desde un plugin
Superpoder — un proceso que el agente está obligado a seguir
Servidor MCP — herramientas reales que el agente maneja, no suposiciones
Automatización — se ejecuta solo: una Action o un script
Directrices — archivos de instrucciones siempre activos
Estado de la incidencia, gobernado por la automatización de staging
La promoción a producción no cambia ningún estado: «Hecho» significa integrado y verificado en staging.
Las directrices bajo cada paso
Nada de esto depende de acordarse de pedirlo bien. Hay cuatro archivos de instrucciones instalados tanto para Kiro como para Claude Code, así que ambos agentes trabajan con los mismos estándares antes de escribir el primer prompt.
AGENTS.mdLos estándares de ingeniería: el stack por defecto, cómo se prueba y qué significa «terminado» en el trabajo de interfaz.
project-workflow.mdCómo un problema se convierte en incidencias, las incidencias en especificaciones y el tablero se mantiene sincronizado solo.
git-workflow.mdDisciplina de ramas y publicaciones: staging integra, main es producción y la promoción siempre es deliberada.
amplify-deploy.mdLas reglas de despliegue aprendidas a golpes: el control de npm ci, el límite de cómputo SSR y la configuración de build que sí funciona.
Escritos una vez, versionados en un repositorio y propagados a cada proyecto: lo aprendido en un desarrollo se aplica al siguiente.