@cristiancorreau/forge 2.1.0

package/assets/adapters/claude-code/commands/work.md

@@ -0,0 +1,101 @@
+# work
+
+Implementa una spec con un agent team. Flags soportados: `--serial`, `--autorun`.
+
+Scope: $ARGUMENTS (ej: `--serial`, `--autorun`, o vacío para modo paralelo estándar)
+
+## Paso 1 — Identificar la spec
+
+Buscar archivos `.md` en `docs/specs/` que contengan `**Estado:** ready`.
+
+- Si hay exactamente una: mostrarla y confirmar "Implementando: `<archivo>`."
+- Si hay varias: mostrarlas como lista numerada y pedir que el usuario elija.
+- Si no hay ninguna: "No hay spec en estado ready. Ejecutá `/plan` primero." y detener.
+
+Leer la spec seleccionada completa antes de continuar.
+
+## Paso 2 — Leer configuración del proyecto
+
+Leer `project.yaml` si existe. Obtener:
+- `project.mode` (startup/standard/enterprise) — default: startup si no existe
+- `agents.active` — lista de agentes disponibles
+- `agents.by_role` — mapeo de roles a agentes
+- `agents.profiles` — profiles activos
+
+Si `project.yaml` no existe, continuar con defaults: mode=startup, team mínimo.
+
+## Paso 3 — Proponer composición del team
+
+Evaluar la naturaleza de la tarea según el acceptance criteria de la spec:
+
+**Cuándo NO crear team (usar `--serial` implícitamente):**
+- Cambio en un solo archivo
+- Bugfix trivial sin impacto en otros módulos
+- Tarea de lectura o análisis de código
+
+**Composición según mode:**
+
+| Mode | Team típico | Tamaño |
+|------|-------------|--------|
+| startup | orchestrator + 1 especialista | 2 agentes |
+| standard | orchestrator + backend + frontend + test-engineer | 3-4 agentes |
+| enterprise | orchestrator + backend + frontend + test-engineer + compliance-reviewer o security-auditor | 4-5 agentes |
+
+Límites absolutos: máximo 5-6 tasks por teammate, máximo 5 teammates.
+
+Mostrar el team propuesto con el rol y la tarea concreta de cada agente. Ejemplo:
+```
+Team propuesto:
+- orchestrator: coordinar implementación y resolver dependencias entre módulos
+- backend-engineer: implementar endpoints de API y lógica de negocio
+- frontend-engineer: construir componentes UI y conectar con la API
+- test-engineer: escribir tests unitarios e integración para los cambios
+```
+
+## Paso 4 — Confirmar con el usuario
+
+Preguntar: "¿Aprobás este team o querés ajustarlo?"
+
+Si el usuario ajusta: modificar el team según su feedback antes de ejecutar.
+
+Si se detectó que la tarea no requiere team (ver criterios arriba): informar "Esta tarea es simple — implementaré en modo serial sin team." y continuar con modo `--serial`.
+
+## Paso 5 — Ejecutar
+
+### Con `--serial` (o tarea simple detectada en Paso 3)
+
+Implementar secuencialmente sin subagentes. Seguir el acceptance criteria de la spec como checklist. Reportar progreso por ítem.
+
+### Sin flags (modo paralelo estándar)
+
+Antes de ejecutar: si se usó `--autorun`, advertir una sola vez: "Modo --autorun activado: ejecutaré hasta completar sin confirmaciones intermedias. Esto es experimental."
+
+Spawnar cada teammate con:
+
+```
+Agent({
+  subagent_type: "<nombre-agente>",
+  description: "<rol y tarea concreta en una línea>",
+  prompt: "<prompt auto-contenido con: contexto completo del proyecto, spec completa, tarea específica del agente, instrucciones de qué reportar al terminar>",
+  run_in_background: true
+})
+```
+
+El prompt de cada agente debe ser auto-contenido: incluir la spec completa, el stack técnico del proyecto y la tarea específica. El agente no tiene acceso al contexto de esta sesión.
+
+## Paso 6 — Monitorear y sintetizar
+
+Cuando los teammates terminan:
+- Revisar los resultados de cada uno
+- Identificar conflictos o dependencias no resueltas
+- Reportar al usuario: qué implementó cada agente, qué tests pasaron, si hubo errores
+
+Si hay errores o conflictos: reportar claramente y preguntar cómo proceder. No resolver conflictos automáticamente sin confirmación.
+
+## Paso 7 — Actualizar la spec
+
+- Al iniciar la implementación: cambiar `**Estado:** ready` → `**Estado:** in-progress`
+- Al completar exitosamente: cambiar `**Estado:** in-progress` → `**Estado:** implemented`
+- Completar las secciones "Implementation notes" y "Decisiones tomadas" con lo que se hizo
+
+Confirmar: "Implementación completa. Spec actualizada a `implemented`. Podés ejecutar `/review` y luego `/ship`."

package/assets/adapters/claude-code/generate-claude-md.py

@@ -0,0 +1,304 @@
+#!/usr/bin/env python3
+# Copyright 2026 Cristian Correa — Apache License 2.0
+# https://github.com/cristiancorreau/forge
+"""
+Genera CLAUDE.md para un proyecto usando forge.
+
+Usage:
+  python3 .agentic/adapters/claude-code/generate-claude-md.py
+
+Lee project.yaml en la raíz y genera CLAUDE.md adaptado al stack del proyecto.
+Si ya existe un CLAUDE.md, muestra el diff antes de sobreescribir.
+
+Requiere: pyyaml
+"""
+import os
+import sys
+from pathlib import Path
+
+FORCE = "--force" in sys.argv
+
+try:
+    import yaml
+except ImportError:
+    print("ERROR: pyyaml requerido. pip install pyyaml", file=sys.stderr)
+    sys.exit(1)
+
+
+def find_project_root() -> Path:
+    here = Path.cwd()
+    for p in [here] + list(here.parents):
+        if (p / "project.yaml").exists():
+            return p
+    raise FileNotFoundError("No se encontró project.yaml")
+
+
+def _render_phases(config: dict) -> str:
+    sprint = config.get("sprint", {})
+    current = sprint.get("current", 1)
+    phases = sprint.get("phases", [])
+    if not phases:
+        return (
+            f"- **Sprint actual:** Sprint {current}\n"
+            "- **Completadas:** —\n"
+            "- **En curso:** —\n"
+            "- **Pendientes:** —"
+        )
+    lines = [f"- **Sprint actual:** Sprint {current}"]
+    for phase in phases:
+        pid = phase.get("id", "?")
+        name = phase.get("name", "")
+        specs = phase.get("specs", [])
+        status = phase.get("status", "pendiente")
+        spec_list = ", ".join(specs) if specs else "—"
+        lines.append(f"- **Fase {pid} — {name}** ({status}): {spec_list}")
+    return "\n".join(lines)
+
+
+_AGENT_TRIGGER = {
+    "orchestrator":        ("tareas multi-agente, análisis de >3 archivos, descomposición de features completas", None),
+    "backend-engineer":    ("endpoints, middleware, validaciones, lógica de negocio", "api"),
+    "api-engineer":        ("endpoints REST, middleware, validaciones, migraciones de BD", "api"),
+    "frontend-engineer":   ("componentes UI, páginas, estilos, integración con API", "frontend"),
+    "admin-engineer":      ("UI de gestión interna, dashboards de admin", "admin"),
+    "mobile-engineer":     ("pantallas móviles, navegación, stores de estado", "mobile"),
+    "fullstack-engineer":  ("features full-stack end-to-end que abarcan backend y frontend", None),
+    "test-engineer":       ("tests unitarios, integración, E2E — nunca código de producción", "tests"),
+    "docs-writer":         ("specs, ADRs, READMEs, documentación — nunca código de producción", "specs"),
+    "compliance-reviewer": ("revisión de PRs con PII, consentimientos, logs de auditoría", None),
+    "security-auditor":    ("auditoría de vulnerabilidades, revisión de dependencias, pentest", None),
+    "migration-specialist": ("migraciones de versión de framework (ej: L6→L13)", "migrations"),
+    "wp-engineer":         ("temas WordPress, FSE, Gutenberg, child themes", "frontend"),
+    "divi-engineer":       ("layouts Divi 5, módulos custom, Divi Builder", "frontend"),
+    "elementor-engineer":  ("templates Elementor Pro, widgets custom", "frontend"),
+    "scanner-engineer":    ("scraping, crawling, extracción estructurada de datos", "scanner"),
+}
+
+
+def _build_agent_scope_table(agents_cfg: dict, paths: dict) -> str:
+    active = agents_cfg.get("active", [])
+    compliance = agents_cfg.get("compliance", [])
+    agent_paths = {**(paths or {})}
+    rows = []
+    for agent in active + compliance:
+        trigger, path_key = _AGENT_TRIGGER.get(agent, ("implementación", None))
+        scope = agent_paths.get(path_key) if path_key else None
+        scope_str = f"`{scope}`" if scope else "`/`"
+        rows.append(f"| `{agent}` | {scope_str} | {trigger} |")
+    if not rows:
+        return ""
+    header = (
+        "## Agentes y su scope\n\n"
+        "| Agente | Scope | Cuándo usarlo |\n"
+        "|--------|-------|---------------|\n"
+    )
+    return header + "\n".join(rows) + "\n\n> Invocar el agente del scope correcto, no el orchestrator, para tareas acotadas.\n\n"
+
+
+def generate_claude_md(config: dict) -> str:
+    proj = config.get("project", {})
+    stack = config.get("stack", {})
+    team = config.get("team", {})
+    compliance_cfg = config.get("compliance", {})
+    agents_cfg = config.get("agents", {})
+    paths = config.get("paths", {})
+
+    name = proj.get("name", "Mi Proyecto")
+    description = proj.get("description", "")
+    language = proj.get("language", "typescript")
+    backend = stack.get("backend") or "N/A"
+    frontend = stack.get("frontend") or "N/A"
+    database = stack.get("database") or "N/A"
+    frameworks = compliance_cfg.get("frameworks", [])
+    specs_path = paths.get("specs", "docs/specs")
+    progress_path = paths.get("progress", "docs/progress.html")
+    agent_scope_section = _build_agent_scope_table(agents_cfg, paths)
+
+    # Agentes activos
+    active = agents_cfg.get("active", [])
+
+    # Comandos según lenguaje
+    if language == "typescript":
+        dev_cmd = "pnpm dev"
+        test_cmd = "pnpm test"
+        lint_cmd = "pnpm lint"
+        build_cmd = "pnpm build"
+    elif language == "python":
+        dev_cmd = "python manage.py runserver  # o uvicorn main:app"
+        test_cmd = "pytest"
+        lint_cmd = "ruff check ."
+        build_cmd = "# no aplica"
+    elif language == "ruby":
+        dev_cmd = "rails server"
+        test_cmd = "bundle exec rspec"
+        lint_cmd = "rubocop"
+        build_cmd = "# no aplica"
+    elif language == "go":
+        dev_cmd = "go run ./cmd/..."
+        test_cmd = "go test ./..."
+        lint_cmd = "golangci-lint run"
+        build_cmd = "go build ./..."
+    elif language == "php":
+        dev_cmd = "php artisan serve  # o php -S localhost:8000 -t public"
+        test_cmd = "vendor/bin/phpunit  # o ./vendor/bin/pest"
+        lint_cmd = "vendor/bin/phpstan analyse"
+        build_cmd = "composer install --no-dev --optimize-autoloader"
+    elif language == "mixed":
+        dev_cmd = "# ver documentación del proyecto (stack mixto)"
+        test_cmd = "# ver documentación del proyecto (stack mixto)"
+        lint_cmd = "# ver documentación del proyecto (stack mixto)"
+        build_cmd = "# ver documentación del proyecto (stack mixto)"
+    else:
+        dev_cmd = "# ver documentación del proyecto"
+        test_cmd = "# ver documentación del proyecto"
+        lint_cmd = "# ver documentación del proyecto"
+        build_cmd = "# ver documentación del proyecto"
+
+    compliance_section = ""
+    if frameworks:
+        compliance_section = f"""
+## Compliance activo
+
+Este proyecto opera bajo los siguientes marcos regulatorios:
+{chr(10).join(f'- **{f.upper()}**' for f in frameworks)}
+
+Reglas no-negociables:
+- Sin datos personales en logs de stdout
+- Consentimiento explícito antes de cualquier tracker no esencial
+- Logs de auditoría append-only (sin UPDATE/DELETE)
+- Derechos del titular implementados (acceso, rectificación, supresión, oposición, portabilidad)
+"""
+
+    return f"""# CLAUDE.md — {name}
+
+> Generado por forge. Actualizar project.yaml para cambiar la configuración.
+> Si actualizás el código de manera que invalide algo aquí, actualizá este archivo en el mismo PR.
+
+## Misión del proyecto
+
+{description}
+
+## Stack
+
+- **Lenguaje**: {language}
+- **Backend**: {backend}
+- **Frontend**: {frontend}
+- **Base de datos**: {database}
+- **Testing**: {", ".join(stack.get("testing", []))}
+
+{agent_scope_section}## Estructura
+
+```
+{proj.get("slug", "proyecto")}/
+├── CLAUDE.md                    ← Estás acá
+├── AGENTS.md                    ← Convenciones del agent team
+├── project.yaml                 ← Config de forge (fuente de verdad)
+├── {specs_path}/                ← Specs de features (requeridas antes de implementar)
+└── {progress_path}              ← Dashboard de progreso del proyecto
+```
+
+## Cómo trabajar (SDD)
+
+Cuando recibás una tarea:
+
+1. **Identificá la spec.** Si no está en `{specs_path}/`, pará y pedí que se cree.
+2. **Leé la spec correspondiente.**
+3. **Leé el `CLAUDE.md` del módulo** que vas a modificar (si existe).
+4. **Proponé opciones** para decisiones arquitectónicas no cubiertas por la spec.
+5. **Esperá aprobación** antes de generar código.
+6. **Tests** junto con la implementación, no al final.
+7. **Al terminar**, actualizá la spec con decisiones tomadas durante la implementación.
+8. **Antes de cerrar**: `{test_cmd}`, `{lint_cmd}`.
+{compliance_section}
+## Phases activas y estado
+
+{_render_phases(config)}
+
+> Actualizar `project.yaml` (sprint.phases) para reflejar el estado real.
+
+## Comandos frecuentes
+
+```bash
+{dev_cmd}     # Desarrollo
+{test_cmd}    # Tests
+{lint_cmd}    # Lint
+{build_cmd}   # Build
+```
+
+## Qué NO hacer
+
+- No implementar sin spec en `{specs_path}/`
+- No hardcodear tokens, passwords o secrets
+- No usar `any` en TypeScript sin comentario que explique por qué
+- No commits con `console.log` o `print` de depuración
+- No hacer force push a main/master
+"""
+
+
+def _generate_architecture_rules(root: Path, forge: Path, config: dict):
+    """Crea .claude/architecture.rules desde el template si no existe. Nunca sobreescribe."""
+    dst = root / ".claude" / "architecture.rules"
+    if dst.exists():
+        return
+
+    # Buscar el template en forge
+    tpl_path = forge / "core" / "templates" / "claude-md" / "architecture.rules"
+    if not tpl_path.exists():
+        return
+
+    project_name = config.get("project", {}).get("name", "Mi Proyecto")
+    content = tpl_path.read_text(encoding="utf-8")
+    content = content.replace("<NOMBRE_PROYECTO>", project_name)
+
+    dst.parent.mkdir(parents=True, exist_ok=True)
+    dst.write_text(content, encoding="utf-8")
+    print(f"[OK] .claude/architecture.rules — creado desde template")
+
+
+def _find_forge_dir(root: Path) -> Path:
+    """Localiza el directorio de forge relativo a este script."""
+    # Este script está en forge/adapters/claude-code/generate-claude-md.py
+    script_dir = Path(__file__).parent
+    # forge_dir = forge/
+    candidate = script_dir.parent.parent
+    if (candidate / "core").exists():
+        return candidate
+    # Fallback: buscar .agentic o forge en la raíz del proyecto
+    for name in (".agentic", "forge"):
+        c = root / name
+        if (c / "core").exists():
+            return c
+    return candidate
+
+
+def main():
+    try:
+        root = find_project_root()
+    except FileNotFoundError as e:
+        print(f"ERROR: {e}", file=sys.stderr)
+        sys.exit(1)
+
+    with open(root / "project.yaml") as f:
+        config = yaml.safe_load(f)
+
+    content = generate_claude_md(config)
+    output_path = root / "CLAUDE.md"
+
+    if output_path.exists() and not FORCE:
+        print(f"CLAUDE.md ya existe en {root}. Sobreescribir? [s/N] ", end="")
+        resp = input().strip().lower()
+        if resp not in ("s", "si", "sí", "y", "yes"):
+            print("Cancelado.")
+            sys.exit(0)
+
+    with open(output_path, "w") as f:
+        f.write(content)
+
+    print(f"CLAUDE.md generado en {output_path}")
+
+    forge = _find_forge_dir(root)
+    _generate_architecture_rules(root, forge, config)
+
+
+if __name__ == "__main__":
+    main()

package/assets/adapters/codex/commands/plan.md

@@ -0,0 +1,63 @@
+---
+name: plan
+description: Template para planificar una feature con Codex CLI siguiendo SDD
+usage: Copia el contenido de Prompt en tu sesión de Codex
+---
+
+## Prompt para Codex
+
+Quiero planificar la siguiente feature: [NOMBRE O DESCRIPCIÓN DE LA FEATURE]
+
+Sigue estos pasos en orden:
+
+1. Busca si existe una spec para esta feature en `docs/specs/`. Lista los archivos en ese directorio y lee cualquiera que sea relevante.
+
+2. Si NO existe spec:
+   - Crea el archivo `docs/specs/[ID]-[nombre-kebab-case].md` usando la plantilla en `docs/specs/_template.md` (si existe) o con esta estructura:
+     ```
+     # [Nombre de la Feature]
+     > Estado: DRAFT
+     > Fecha: [fecha actual]
+
+     ## Contexto
+     [Por qué existe esta feature]
+
+     ## Decisión
+     [Qué vamos a implementar exactamente]
+
+     ## Criterios de aceptación
+     - [ ] [criterio verificable 1]
+     - [ ] [criterio verificable 2]
+
+     ## Notas de implementación
+     [Vacío — se completa durante la implementación]
+     ```
+   - Detente aquí. No escribas ningún código hasta que la spec esté aprobada.
+
+3. Si la spec existe y está en estado APPROVED:
+   - Lee la spec completa.
+   - Lee el `project.yaml` en la raíz para entender el stack.
+   - Identifica los archivos que deberán modificarse.
+   - Propón el plan de implementación con este formato:
+     ```
+     PLAN: [nombre de la feature]
+
+     Archivos a crear:
+     - [ruta exacta]: [propósito]
+
+     Archivos a modificar:
+     - [ruta exacta]: [qué cambia]
+
+     Orden de implementación:
+     1. [paso 1]
+     2. [paso 2]
+
+     Tests necesarios:
+     - [ruta de test]: [qué verifica]
+     ```
+   - No implementes nada todavía. Espera confirmación explícita.
+
+Restricciones:
+- Nunca hardcodear tokens, passwords ni secrets.
+- No crear código antes de que exista spec aprobada.
+- Si la feature afecta autenticación, rutas de API, o manejo de PII — mencionarlo explícitamente en el plan.

package/assets/adapters/codex/commands/review.md

@@ -0,0 +1,53 @@
+---
+name: review
+description: Template para revisar código con Codex CLI
+usage: Copia el contenido de Prompt en tu sesión de Codex
+---
+
+## Prompt para Codex
+
+Revisa el siguiente código o cambios: [RUTA DE ARCHIVO, RAMA, O "cambios sin commitear actuales"]
+
+Ejecuta esta revisión en orden:
+
+1. **Identificar el scope**
+   - Si es un archivo: lee ese archivo completo.
+   - Si es "cambios sin commitear": ejecuta `git diff` y `git diff --cached` para ver todos los cambios.
+   - Si es una rama: ejecuta `git diff main...[nombre-rama]` para ver los cambios respecto a main.
+
+2. **Checklist de seguridad**
+   - [ ] ¿Hay tokens, passwords o secrets hardcodeados? (busca patrones como `password =`, `token =`, `api_key =`)
+   - [ ] ¿Los endpoints de API verifican autenticación?
+   - [ ] ¿Los endpoints de API verifican autorización (permisos por rol o ownership)?
+   - [ ] ¿Las queries SQL usan parámetros preparados? (nunca concatenación de strings con input del usuario)
+   - [ ] ¿Hay XSS potencial (inserción de HTML sin escapar)?
+   - [ ] ¿Los errores exponen detalles técnicos en respuestas de producción?
+
+3. **Checklist de calidad**
+   - [ ] ¿El código tiene tests que lo verifican?
+   - [ ] ¿Hay queries N+1 o loops en caminos críticos?
+   - [ ] ¿Hay console.log / print de depuración que no deba estar?
+   - [ ] ¿Hay código muerto o duplicado?
+   - [ ] ¿El naming es claro y consistente con el resto del proyecto?
+
+4. **Checklist de compliance** (si el proyecto maneja PII)
+   - [ ] ¿Se está guardando PII en logs?
+   - [ ] ¿Hay cambios en endpoints de derechos del titular (DSAR)?
+   - [ ] ¿Hay cambios en consentimientos o logs de auditoría?
+
+5. **Formato del reporte**
+   Presenta los hallazgos así:
+   ```
+   BLOQUEANTES (deben resolverse antes del merge):
+   - [archivo:línea] descripción del problema
+
+   ADVERTENCIAS (recomendado resolver):
+   - [archivo:línea] descripción
+
+   SUGERENCIAS (opcionales):
+   - descripción
+
+   APROBADO: Sí / No
+   ```
+
+Si no hay bloqueantes ni advertencias, reporta simplemente: "Revisión completada — sin issues encontrados."

package/assets/adapters/codex/commands/session-close.md

@@ -0,0 +1,53 @@
+---
+name: session-close
+description: Template para cerrar una sesión de trabajo con Codex CLI
+usage: Copia el contenido de Prompt al final de tu sesión de Codex
+---
+
+## Prompt para Codex
+
+Cierra la sesión de trabajo. Ejecuta estos checks en orden:
+
+1. **Verificar estado del trabajo**
+   - Ejecuta `git status --short`.
+   - Si hay cambios sin commitear: listarlos. ¿Deben commitearse o descartarse?
+   - Ejecuta `git diff --stat HEAD` para ver el resumen de cambios en el último commit.
+
+2. **Verificar build y tests**
+   - Lee `project.yaml` para el comando de check configurado (`scripts.check`).
+   - Si no hay comando configurado: ejecuta el check estándar del stack (tsc --noEmit para TypeScript, py_compile para Python).
+   - Reporta si pasan o fallan. Si fallan, listar los errores.
+
+3. **Verificar specs**
+   - Lee `AGENTS.md` o `CLAUDE.md` para ver el estado de specs activas.
+   - Lista specs en `docs/specs/` con estado `APPROVED` que no estén `IMPLEMENTED`.
+   - ¿Hay specs en progreso que quedaron incompletas esta sesión? Reportarlas.
+
+4. **Registrar progreso**
+   - ¿Qué se completó en esta sesión? Lista los archivos modificados:
+     `git diff --name-only HEAD~1 HEAD 2>/dev/null || git diff --name-only`
+   - ¿Qué quedó pendiente?
+   - ¿Hay bloqueadores para la próxima sesión?
+
+5. **Verificar debug statements olvidados**
+   - Ejecuta en archivos modificados: busca `console.log(`, `print(`, `debugger;`.
+   - Si hay alguno: listarlos con archivo y línea.
+
+6. **Reporte de cierre**
+   Presenta este resumen:
+   ```
+   Sesión cerrada — [fecha]
+
+   Completado:
+   - [item 1]
+   - [item 2]
+
+   Pendiente para próxima sesión:
+   - [item 1]
+
+   Bloqueadores:
+   - [item o "ninguno"]
+
+   Estado del repo: [limpio | N archivos con cambios]
+   Tests: [pasando | fallando]
+   ```

package/assets/adapters/codex/commands/session-start.md

@@ -0,0 +1,49 @@
+---
+name: session-start
+description: Template para iniciar una sesión de trabajo con Codex CLI
+usage: Copia el contenido de Prompt al inicio de tu sesión de Codex
+---
+
+## Prompt para Codex
+
+Inicia la sesión de trabajo. Ejecuta estos checks en orden y reporta el resultado:
+
+1. **Verificar herramientas disponibles**
+   - Ejecuta `git --version` — reporta la versión o error.
+   - Ejecuta `python3 --version` — reporta la versión o error.
+   - Si alguna herramienta crítica falta, reporta el error y detente.
+
+2. **Verificar branch actual**
+   - Ejecuta `git branch --show-current`.
+   - Si el resultado es `main` o `master`: advierte que estás en la branch protegida.
+     Sugiere: `git checkout -b feature/<tema>-$(date +%Y-%m-%d)`
+   - Si estás en una feature branch: OK.
+
+3. **Verificar cambios sin commitear**
+   - Ejecuta `git status --short`.
+   - Si hay cambios: listarlos y advertir.
+   - Si no hay cambios: OK.
+
+4. **Verificar project.yaml**
+   - Busca `project.yaml` en el directorio actual y directorios padre (hasta 3 niveles).
+   - Si no existe: advierte que el proyecto no está inicializado con Forge. Sugiere ejecutar el wizard.
+   - Si existe: lee los campos `project.name` y `project.mode`.
+     - Si faltan esos campos: advertir.
+     - Si están presentes: reportar nombre y modo del proyecto.
+
+5. **Verificar variables de producción activas**
+   - Ejecuta `env | grep -iE '^(PROD_|PRODUCTION_)'`.
+   - Si hay variables de producción activas: ADVERTENCIA — verificar que es intencional trabajar con contexto de producción.
+   - Si no hay ninguna: OK.
+
+6. **Leer AGENTS.md**
+   - Lee `AGENTS.md` en la raíz del repositorio.
+   - Confirma que lo leíste y resume el nombre del proyecto y el workflow activo.
+
+Formato del reporte final:
+```
+Sesión iniciada — [nombre del proyecto]
+Branch: [nombre]
+Estado: [limpio | N cambios sin commitear]
+Warnings: [lista o "ninguno"]
+```

package/assets/adapters/codex/commands/ship.md

@@ -0,0 +1,53 @@
+---
+name: ship
+description: Template para preparar y verificar el deploy con Codex CLI
+usage: Copia el contenido de Prompt en tu sesión de Codex
+---
+
+## Prompt para Codex
+
+Prepara el proyecto para deploy en: [ENTORNO: staging | production]
+
+Ejecuta estos checks en orden y reporta el resultado de cada uno:
+
+1. **Verificar estado del worktree**
+   - Ejecuta `git status` — ¿hay cambios sin commitear?
+   - Ejecuta `git branch --show-current` — ¿estás en la branch correcta?
+   - Si hay cambios sin commitear, detente y reporta cuáles son.
+
+2. **Ejecutar tests**
+   - Lee `project.yaml` para encontrar el comando de tests (`scripts.test`).
+   - Si no está configurado, ejecuta el comando estándar del stack:
+     - Node.js: `npm test` o `pnpm test`
+     - Python: `pytest`
+     - Ruby: `bundle exec rspec`
+   - Si los tests fallan, detente. No continuar con el deploy.
+
+3. **Verificar build**
+   - Lee `project.yaml` para encontrar el comando de build (`scripts.build`).
+   - Ejecuta el build y reporta si pasa o falla.
+   - Busca errores de TypeScript: `tsc --noEmit` si es un proyecto TypeScript.
+
+4. **Verificar variables de entorno**
+   - Lee `.env.example` si existe — lista las variables requeridas.
+   - Verifica que todas estén documentadas.
+   - Busca cualquier variable de entorno hardcodeada en el código (grep por `process.env` sin variable de entorno correspondiente en `.env.example`).
+
+5. **Buscar debug statements**
+   - Ejecuta: `git diff main --name-only` para ver archivos cambiados.
+   - Busca `console.log(`, `print(`, `debugger;`, `var_dump(` en esos archivos.
+   - Reporta cada ocurrencia encontrada.
+
+6. **Verificar specs implementadas**
+   - Lista los specs en `docs/specs/` con estado `APPROVED` (sin `IMPLEMENTED`).
+   - Si hay specs aprobadas sin implementar que se esperaban en este deploy, reportarlas.
+
+7. **Confirmar proveedor de deploy**
+   - Lee `project.yaml` sección `deploy`.
+   - Reporta: URL de producción, proveedor, branch de deploy.
+   - Si el entorno es `production` y no hay evidencia de que `staging` fue validado primero, advertirlo.
+
+Restricciones:
+- Nunca hacer force push a main/master.
+- No continuar si los tests fallan.
+- Si el entorno es `production`, confirmar explícitamente antes de ejecutar cualquier comando de deploy.