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:brainstorming

    Explora 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

Por hacer
En curso
Hecho

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.md

    Los estándares de ingeniería: el stack por defecto, cómo se prueba y qué significa «terminado» en el trabajo de interfaz.

  • project-workflow.md

    Cómo un problema se convierte en incidencias, las incidencias en especificaciones y el tablero se mantiene sincronizado solo.

  • git-workflow.md

    Disciplina de ramas y publicaciones: staging integra, main es producción y la promoción siempre es deliberada.

  • amplify-deploy.md

    Las 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.

En reproducción — selecciona cualquier paso para explorarlo tú mismo.