@cristiancorreau/forge 2.1.0

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

@@ -0,0 +1,116 @@
+# plan
+
+Gestiona specs del ciclo SDD (Spec-Driven Development).
+
+Scope: $ARGUMENTS (ej: `2 "Auth con OAuth"` para crear spec, `--review <archivo>` para revisar, vacío para listar)
+
+## Modo crear spec (`/plan <fase> "<título>"`)
+
+### Paso 1 — Verificar directorio
+
+Verificar que existe `docs/specs/`. Si no existe, crearlo.
+
+### Paso 2 — Crear el archivo de spec
+
+Construir el nombre del archivo:
+- Tomar el título, convertirlo a minúsculas, reemplazar espacios por guiones, eliminar caracteres especiales → `<slug>`
+- Nombre final: `docs/specs/<fase>-<slug>.md`
+
+Crear el archivo con este template exacto:
+
+```markdown
+# Spec: <título>
+**Fase:** <fase> | **Estado:** draft | **Fecha:** YYYY-MM-DD
+
+## Problem statement
+[¿Qué problema resuelve? ¿Por qué ahora?]
+
+## Non-goals
+[Qué NO cubre esta spec]
+
+## Acceptance criteria
+- [ ] Criterio 1 (verificable, testeable)
+- [ ] Criterio 2
+
+## Compliance mapping
+[Si el proyecto tiene frameworks de compliance en project.yaml, mapear qué artículos aplican. Si no aplica, escribir "N/A".]
+
+## Edge cases
+[Casos límite que la implementación debe manejar]
+
+## Implementation notes
+[Se llena durante la implementación]
+
+## Decisiones tomadas
+[Se llena durante la implementación]
+```
+
+### Paso 3 — Guiar al usuario por cada sección
+
+Preguntar una sección a la vez, en orden:
+
+1. "¿Qué problema concreto resuelve esta feature? ¿Por qué ahora y no más adelante?"
+2. "¿Qué queda explícitamente fuera del scope de esta spec?"
+3. "¿Cuáles son los criterios de aceptación verificables? (cada uno debe ser testeable de forma objetiva)"
+4. Si `project.yaml` tiene frameworks de compliance: "¿Qué artículos o controles de compliance aplican a esta feature?"
+5. "¿Qué casos límite debe manejar la implementación? (ej: usuario sin permisos, datos vacíos, concurrencia)"
+
+Completar el archivo con las respuestas del usuario a medida que avanza.
+
+### Paso 4 — Planner-Critic (condicional)
+
+Leer `project.yaml` → `project.mode`:
+
+- **mode=standard o mode=enterprise**: aplicar Planner-Critic obligatoriamente
+- **mode=startup**: preguntar "¿Querés aplicar el Planner-Critic para detectar ambigüedades antes de implementar? (s/n)"
+- Si `project.yaml` no existe: tratar como startup
+
+**Cómo aplicar el Planner-Critic:**
+
+Adoptar el rol de "Critic" y revisar la spec completa buscando:
+- ¿Hay acceptance criteria que no son objetivamente verificables?
+- ¿Hay términos ambiguos que diferentes personas podrían interpretar distinto?
+- ¿Hay edge cases no cubiertos que podrían romper la implementación?
+- ¿Los non-goals son suficientemente explícitos para evitar scope creep?
+
+Mostrar las críticas como bullet points. Preguntar: "¿Ajustamos la spec antes de marcarla como ready?"
+
+Si el usuario ajusta: actualizar el archivo y repetir el Critic una vez más.
+
+### Paso 5 — Marcar como ready
+
+Cuando el usuario aprueba la spec (o decide no aplicar el Critic):
+- Cambiar `**Estado:** draft` → `**Estado:** ready` en el archivo
+- Confirmar: "Spec lista: `docs/specs/<archivo>.md`. Ahora podés ejecutar `/work` para implementarla."
+
+---
+
+## Modo listar (`/plan` sin argumentos)
+
+Buscar todos los archivos `.md` en `docs/specs/` que contengan `**Estado:** draft` o `**Estado:** in-review`.
+
+Si no hay ninguno: "No hay specs en estado draft o in-review. Ejecutá `/plan <fase> \"<título>\"` para crear una."
+
+Si hay alguno: mostrarlos como lista numerada con título, fase y fecha. Ejemplo:
+```
+1. auth-oauth.md — Fase 2 — Auth con OAuth (2026-05-17)
+2. billing-webpay.md — Fase 3 — Pago con WebPay (2026-05-14)
+```
+
+Preguntar: "¿Cuál continuamos?"
+
+---
+
+## Modo revisar (`/plan --review <archivo-spec>`)
+
+Leer el archivo de spec indicado.
+
+Aplicar el Planner-Critic completo:
+- ¿Los acceptance criteria son objetivamente testeables?
+- ¿Hay ambigüedades en el problem statement o en los criterios?
+- ¿Hay edge cases no cubiertos?
+- ¿Los non-goals son suficientemente explícitos?
+
+Mostrar sugerencias de mejora como bullet points con la sección específica que afectan.
+
+Preguntar: "¿Aplicamos alguno de estos cambios?"

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

@@ -0,0 +1,219 @@
+# review
+
+Orquesta una revisión de código estructurada y produce un veredicto vinculante para `/ship`.
+
+Scope: $ARGUMENTS (ej: vacío para cambios uncommitted, `HEAD~3..HEAD` para últimos 3 commits, `PR-42` para un PR específico, `--codex` para output en texto plano)
+
+---
+
+## Paso 0 — Determinar modo de invocación
+
+Evaluar `$ARGUMENTS`:
+
+- **Vacío**: revisar cambios uncommitted (`git diff HEAD`)
+- **`HEAD~N..HEAD`** o cualquier rango git válido: revisar ese rango de commits (`git diff <rango>`)
+- **`PR-N`** (ej: `PR-42`): obtener el diff del PR con `gh pr diff 42`
+- **`--codex`**: activar modo Codex CLI — output en texto plano sin markdown ni tablas, misma lógica de revisión
+
+Guardar el scope como descripción legible (ej: "cambios uncommitted", "últimos 3 commits", "PR #42") para incluirlo en el reporte final.
+
+---
+
+## Paso 1 — Obtener el diff
+
+Según el modo detectado en el Paso 0:
+
+- Cambios uncommitted: `git diff HEAD` (si está vacío, probar `git diff --cached`)
+- Rango de commits: `git diff <rango>`
+- PR: `gh pr diff <N>`
+
+Si el diff está vacío: "No hay cambios para revisar en el scope indicado." y detener.
+
+Mostrar un resumen de lo que se va a revisar:
+```
+Revisando: <scope>
+Archivos modificados: <N>
+Líneas añadidas/eliminadas: +X / -Y
+```
+
+---
+
+## Paso 2 — Leer mode del proyecto
+
+Leer `project.yaml` → `project.mode`:
+
+- `startup`: revisión en un solo paso (Paso 3A)
+- `standard`: revisión multi-agente paralela sin compliance (Paso 3B)
+- `enterprise`: revisión multi-agente paralela con compliance (Paso 3B)
+- Si `project.yaml` no existe o no tiene `project.mode`: tratar como `startup`
+
+---
+
+## Paso 3A — Revisión única (modo startup)
+
+Revisar el diff completo cubriendo todas las dimensiones en un solo paso:
+
+**Seguridad**
+- ¿Hay tokens, passwords o claves hardcodeadas?
+- ¿Los endpoints nuevos o modificados verifican autenticación Y autorización?
+- ¿Hay concatenación de input del usuario en queries SQL (riesgo de SQLi)?
+- ¿Hay output de input del usuario sin escapar (riesgo de XSS)?
+- ¿Se loguea PII sin enmascarar?
+
+**Calidad**
+- ¿Hay naming confuso o inconsistente con el resto del proyecto?
+- ¿Hay código muerto o lógica duplicada?
+- ¿Hay N+1 queries o loops en caminos críticos?
+- ¿Faltan índices para queries que se ejecutan frecuentemente?
+
+**Tests**
+- ¿Cada función o endpoint modificado tiene al menos un test correspondiente?
+- ¿Los casos borde están cubiertos?
+
+Ir directamente al Paso 4.
+
+---
+
+## Paso 3B — Revisión multi-agente paralela (modo standard/enterprise)
+
+Lanzar los siguientes agentes en paralelo. Cada uno debe revisar el diff completo enfocándose en su dominio.
+
+### Agente 1 — Security reviewer
+
+Revisar exclusivamente dimensiones de seguridad:
+- Secrets hardcodeados (tokens, passwords, API keys, certificados)
+- Endpoints sin verificación de autenticación o autorización
+- Input del usuario concatenado en queries SQL
+- Output sin escapar que pueda resultar en XSS
+- PII en logs sin enmascarar
+- Dependencias nuevas con vulnerabilidades conocidas
+
+Reportar: lista de hallazgos con severidad (CRITICAL / HIGH / MEDIUM / LOW) y línea exacta.
+
+### Agente 2 — Quality reviewer
+
+Revisar exclusivamente dimensiones de calidad de código:
+- Naming confuso, inconsistente o engañoso
+- Código muerto (funciones no llamadas, variables no usadas)
+- Lógica duplicada que debería extraerse
+- N+1 queries o llamadas a DB dentro de loops
+- Índices faltantes para las queries nuevas o modificadas
+- Violaciones de principios de responsabilidad única del agente
+
+Reportar: lista de hallazgos con descripción y sugerencia de mejora.
+
+### Agente 3 — Test reviewer
+
+Revisar exclusivamente cobertura de tests:
+- Por cada función o endpoint modificado: ¿existe un test que lo cubra?
+- Por cada caso borde identificado en el diff: ¿hay un test para él?
+- ¿Se eliminaron tests sin eliminar también la funcionalidad correspondiente?
+- ¿Los tests nuevos son significativos (no triviales o que siempre pasan)?
+
+Reportar: lista de funciones/endpoints sin cobertura y gaps de casos borde.
+
+### Agente 4 — Compliance reviewer (solo enterprise)
+
+Revisar exclusivamente dimensiones de compliance:
+- ¿Hay cambios en el manejo de PII (recolección, almacenamiento, transmisión)?
+- ¿Se modificaron flujos de consentimiento o se agregaron nuevos?
+- ¿Hay cambios en logs de auditoría (adición, modificación o eliminación de eventos)?
+- ¿Los cambios están alineados con los frameworks de compliance definidos en `project.yaml`?
+
+Reportar: impactos de compliance con referencia al artículo o control específico si aplica.
+
+---
+
+## Paso 4 — Sintetizar veredicto
+
+(Para modo startup: aplicar directamente. Para standard/enterprise: consolidar los reportes de todos los agentes.)
+
+Evaluar la totalidad de los hallazgos y asignar uno de estos veredictos:
+
+### APPROVED
+No hay hallazgos bloqueantes ni cambios requeridos. Los cambios se ven bien.
+
+### CHANGES_REQUESTED
+Hay issues que deben resolverse pero no son críticos. Listar cada uno claramente:
+```
+CHANGES_REQUESTED
+
+Cambios requeridos:
+1. [Descripción del issue] — [archivo:línea si aplica]
+2. [Descripción del issue] — [archivo:línea si aplica]
+```
+
+### BLOCKED
+Hay issues críticos de seguridad, compliance o correctitud que deben resolverse antes de poder hacer `/ship`. Listar cada uno claramente:
+```
+BLOCKED
+
+Issues críticos:
+1. [Descripción] — [archivo:línea si aplica] — Severidad: CRITICAL
+2. [Descripción] — [archivo:línea si aplica] — Severidad: HIGH
+
+Esta sesión no es apta para /ship hasta resolver estos puntos.
+```
+
+---
+
+## Paso 5 — Producir reporte
+
+Formatear el reporte final:
+
+```
+## Code Review — <scope>
+Fecha: YYYY-MM-DD HH:MM
+Modo: <startup|standard|enterprise>
+
+### Hallazgos
+
+#### Seguridad
+[hallazgos o "Sin hallazgos."]
+
+#### Calidad
+[hallazgos o "Sin hallazgos."]
+
+#### Tests
+[hallazgos o "Sin hallazgos."]
+
+#### Compliance (solo enterprise)
+[hallazgos o "Sin hallazgos." o "N/A (modo no-enterprise)"]
+
+---
+
+### Veredicto: <APPROVED|CHANGES_REQUESTED|BLOCKED>
+
+[Detalle del veredicto]
+```
+
+Si el modo es `--codex`: producir el mismo contenido pero en texto plano sin encabezados markdown, sin tablas, sin bloques de código.
+
+---
+
+## Paso 6 — Guardar resultado
+
+Escribir el archivo `.claude/review-status.json` con el resultado:
+
+```json
+{
+  "verdict": "<APPROVED|CHANGES_REQUESTED|BLOCKED>",
+  "reviewer": "claude-code/review",
+  "timestamp": "<ISO 8601>",
+  "scope": "<descripción del scope revisado>"
+}
+```
+
+Si el directorio `.claude/` no existe, crearlo.
+
+Confirmar al usuario: "Review guardado en `.claude/review-status.json`. `/ship` lo leerá para verificar que el review fue aprobado antes de hacer deploy."
+
+---
+
+## Si BLOCKED
+
+Recordar explícitamente al final del reporte:
+
+> **Esta sesión no es apta para `/ship` hasta resolver los puntos bloqueantes listados arriba.**
+
+No sugerir hacer deploy ni continuar con otros pasos hasta que el usuario reporte que los issues fueron resueltos y vuelva a ejecutar `/review`.

package/assets/adapters/claude-code/commands/session-close.md

@@ -0,0 +1,109 @@
+# session-close
+
+Cierra la sesión de trabajo con un pipeline de 8 pasos: commit, changeset, GitHub Projects, daily note, release notes, close commit, sync y PR.
+
+## Paso 1 — Verificar estado
+
+Ejecutar `git status --short` y `git diff --stat HEAD 2>/dev/null`. Reportar qué hay pendiente.
+
+## Paso 2 — Commitear cambios pendientes
+
+Si hay cambios sin commitear:
+
+- Preguntar al usuario: "¿Qué describe este commit? (usa Conventional Commits: feat/fix/chore/docs/refactor/test)"
+- Commitear con: `git add -A && git commit -m "<type>(<scope>): <descripción>"`
+- Incluir siempre en el cuerpo del commit: `Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>`
+
+Si no hay nada que commitear: indicar "Nada pendiente de commitear." y continuar.
+
+## Paso 3 — Changeset (condicional)
+
+Si el commit del Paso 2 fue de tipo `feat:` o `fix:` Y `package.json` contiene `"@changesets/cli"`:
+
+- Ejecutar `npx changeset` para generar el changeset
+
+En cualquier otro caso, omitir este paso sin mencionarlo.
+
+## Paso 4 — GitHub Projects (condicional)
+
+Leer `project.yaml`. Si tiene una sección `github.project` con `number`, `owner` y `repo`:
+
+- Preguntar: "¿Qué issues trabajaste en esta sesión? (números separados por coma, o Enter para saltar)"
+- Si el usuario provee números: ejecutar `gh issue close <N> --comment "Completado en esta sesión"` para cada uno
+- Mover los issues a Done en el proyecto si es posible con gh CLI
+
+Si `project.yaml` no tiene sección `github.project`: indicar "GitHub Projects no configurado en project.yaml." y continuar.
+
+## Paso 5 — Daily note
+
+Crear el directorio `docs/daily-notes/` si no existe.
+
+Determinar:
+- `FECHA`: resultado de `date +%Y-%m-%d`
+- `TEMA`: derivado del nombre de la rama actual, eliminando el prefijo de tipo y el sufijo de fecha (ej: `feature/billing-webpay-2026-05-16` → `billing-webpay`)
+
+Crear el archivo `docs/daily-notes/FECHA-TEMA.md` con este contenido:
+
+```
+# Session FECHA — TEMA
+
+## Completado
+[listar qué se implementó o cambió en esta sesión]
+
+## Archivos modificados
+[output de: git diff --name-only HEAD~1..HEAD 2>/dev/null || git diff --name-only HEAD 2>/dev/null]
+
+## Commits
+[output de: git log --oneline HEAD~3..HEAD]
+
+## Decisiones tomadas
+[preguntar al usuario: "¿Alguna decisión de diseño o arquitectura que vale registrar?"]
+
+## Blockers para próxima sesión
+[preguntar al usuario: "¿Quedó algo bloqueado o incompleto?"]
+```
+
+Completar las secciones "Archivos modificados" y "Commits" con los outputs reales. Completar "Completado", "Decisiones tomadas" y "Blockers" con las respuestas del usuario.
+
+## Paso 6 — RELEASE-NOTES.md
+
+Agregar al final de `RELEASE-NOTES.md` (crear si no existe):
+
+```
+## FECHA — TEMA
+[resumen en una línea de qué cambió]
+```
+
+Usar el resumen de la daily note para redactar la línea.
+
+## Paso 7 — Commit de cierre
+
+Commitear los archivos generados:
+
+```
+git add docs/daily-notes/ RELEASE-NOTES.md && git commit -m "docs(progress): session close FECHA — TEMA"
+```
+
+## Paso 8 — Sync y PR
+
+Ejecutar:
+
+```
+git fetch origin main
+git log HEAD..origin/main --oneline
+```
+
+- Si main tiene commits nuevos: ejecutar `git rebase origin/main` y luego `git push --force-with-lease origin <rama-actual>`
+- Si main no tiene cambios nuevos: ejecutar `git push -u origin <rama-actual>`
+
+Luego crear el PR:
+
+```
+gh pr create --title "<resumen de cambios>" --body "<resumen de sesión tomado de la daily note>"
+```
+
+Si `gh` no está disponible: hacer solo el push y recordar al usuario "Crea el PR manualmente en GitHub."
+
+## Al finalizar el pipeline
+
+Confirmar con: "Sesión cerrada. PR creado: [URL]" o, si gh no estuvo disponible: "Sesión cerrada. Push hecho a [branch] — crea el PR en GitHub."

package/assets/adapters/claude-code/commands/session-start.md

@@ -0,0 +1,59 @@
+# session-start
+
+Inicializa una sesión de trabajo: detecta el estado del repo, identifica el escenario y enruta según corresponda.
+
+## Paso 1 — Leer estado del repo
+
+Ejecutar los siguientes comandos y guardar sus resultados:
+
+- `git branch --show-current` → rama actual
+- `git status --short` → cambios sin commitear
+- `git log --oneline -5` → commits recientes
+- `gh pr list --author @me --state open --json number,title,headRefName 2>/dev/null` → PRs abiertos (saltar si gh no está disponible)
+- `git branch --sort=-committerdate --format='%(refname:short)' | grep -v 'HEAD' | head -8` → ramas recientes
+
+## Paso 2 — Leer configuración del proyecto
+
+- Si existe `project.yaml` en el directorio actual, leerlo para obtener: `project.mode`, `project.name`, `stack.*`, `agents.active`
+- Si existe `docs/wiki/index.md`, leerlo para obtener contexto del proyecto
+- Si ninguno existe, continuar con defaults: mode=startup, sin checks de compliance
+
+## Paso 3 — Evaluar escenario y actuar
+
+### Escenario A — Ya en una rama de feature (no es main/master/develop)
+
+- Mostrar los últimos 5 commits de esta rama para contexto
+- Mostrar archivos con cambios sin commitear si los hay
+- Reportar: "Continuando sesión en [branch]. Contexto: [mensaje del último commit]."
+- Preguntar: "¿Qué trabajamos hoy?"
+
+### Escenario B — En main/master con PRs abiertos o ramas recientes de feature
+
+- Listar los PRs abiertos del Paso 1 como menú numerado
+- Listar las ramas recientes que no sean main/master/develop del Paso 1
+- Preguntar: "¿Continuás uno de estos o arrancamos algo nuevo?"
+- Si el usuario elige continuar uno existente: hacer checkout de esa rama
+- Si el usuario quiere algo nuevo: pasar al flujo del Escenario C
+
+### Escenario C — En main/master sin trabajo previo identificado
+
+- Esperar el primer mensaje del usuario describiendo qué quiere trabajar
+- Antes de cualquier edición de código, proponer un nombre de rama siguiendo la convención:
+  - `feature/<tema-corto>-$(date +%Y-%m-%d)` para features
+  - `fix/<tema-corto>-$(date +%Y-%m-%d)` para correcciones
+  - `chore/<tema-corto>-$(date +%Y-%m-%d)` para tareas técnicas
+  - `docs/<tema-corto>-$(date +%Y-%m-%d)` para documentación
+- Crear la rama: `git checkout -b <nombre-propuesto>`
+- Confirmar: "Branch creada: [nombre]. Listo para trabajar."
+
+## Paso 4 — Recordatorio de reglas de sesión
+
+Una vez determinado el escenario, enunciar estas reglas una sola vez:
+
+"Reglas de sesión: (1) No editar código en main. (2) Conventional Commits. (3) Spec antes de implementar si el proyecto es standard/enterprise. (4) Cerrar con /session-close."
+
+## Comportamiento adaptativo
+
+- Si `gh` no está disponible: omitir los pasos que lo requieren y agregar nota "gh no disponible — revisar PRs en GitHub.com manualmente"
+- Si `project.yaml` no existe: continuar con defaults, no interrumpir el flujo
+- Si la rama actual no sigue la convención de nombres: mencionarlo pero no bloquear

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

@@ -0,0 +1,133 @@
+# ship
+
+Pipeline de deploy de 10 pasos. Solo disponible cuando `project.yaml` tiene sección `deploy`.
+
+## Verificación inicial
+
+Leer `project.yaml`. Si no existe sección `deploy`: "deploy no configurado en project.yaml. Agregá la sección deploy para usar /ship." y detener.
+
+---
+
+## Paso 1 — Verificar review
+
+Buscar en el contexto de la sesión si se ejecutó `/review` y resultó en APPROVED.
+
+- Si hay evidencia de review aprobado: continuar.
+- Si no hay evidencia: "¿Confirmás que el código fue revisado y aprobado? (s/n)"
+  - Si n: "Ejecutá `/review` antes de hacer deploy." y detener.
+
+## Paso 2 — Verificar git status
+
+Ejecutar `git status --short`.
+
+Si hay cambios sin commitear: "Hay cambios sin commitear. Commiteá primero antes de hacer deploy." y detener.
+
+Si el working tree está limpio: continuar.
+
+## Paso 3 — Merge PR a main (condicional)
+
+Preguntar: "¿Querés mergear el PR actual a main antes del deploy? (s/n)"
+
+Si sí:
+- Ejecutar `gh pr checks` para verificar que todos los checks pasan
+- Si algún check falla: "El PR tiene checks fallando. Resolvelos antes de mergear." y detener.
+- Si todos pasan: ejecutar `gh pr merge --merge` (o la estrategia configurada en `project.yaml` → `deploy.merge_strategy`)
+
+Si no: continuar sin mergear.
+
+## Paso 4 — Trigger deploy
+
+Leer `project.yaml` → `deploy.provider`:
+
+- **vercel**: el deploy se triggeará automáticamente con el merge/push. Ejecutar `gh api repos/:owner/:repo/deployments --jq '.[0].id'` o `vercel ls --json | jq '.[0].uid'` para obtener el deployment ID más reciente. Guardar este ID para el polling.
+- **railway**: ejecutar `railway up` si está disponible en el PATH.
+- **fly**: ejecutar `fly deploy`.
+- **aws**: indicar el comando apropiado según la configuración y pedir al usuario que lo ejecute.
+- Provider no reconocido: "Provider '`<valor>`' no reconocido. Soportados: vercel, railway, fly, aws."
+
+## Paso 5-8 — Polling de estado con backoff
+
+**REGLA CRITICA: máximo 1 consulta al estado del deploy por minuto. Esta regla existe porque los providers rate-limitan su API. Nunca encadenar polls consecutivos sin pausa.**
+
+Loop de polling (máximo 20 intentos = 20 minutos):
+
+```
+Para cada intento:
+  1. Consultar estado del deploy (una sola consulta)
+  2. Evaluar resultado:
+     - BUILDING / QUEUED / IN_PROGRESS:
+         Reportar: "Deploy en progreso (intento N/20)... esperando 60 segundos."
+         Esperar 60 segundos antes del siguiente poll.
+     - ERROR / FAILED / CANCELED:
+         Leer build logs completos.
+         Reportar el error al usuario con los logs relevantes.
+         DETENER — no continuar al Paso 9.
+     - READY / SUCCESS:
+         Continuar al Paso 9.
+  3. Si se alcanzan 20 intentos sin READY: reportar timeout y detener.
+```
+
+**Consultas según provider:**
+- Vercel: `vercel inspect <deployment-id> --json | jq '.readyState'`
+- Railway: `railway status`
+- Fly: `fly status`
+
+## Paso 9 — Verificar runtime logs
+
+Leer los primeros 60 segundos de logs post-deploy:
+- Vercel: `vercel logs <deployment-url> --since 1m`
+- Railway/Fly: logs equivalentes del provider
+
+Si hay errores en los logs:
+- Reportar los errores al usuario con contexto
+- Sugerir rollback: "¿Querés hacer rollback al deploy anterior? (s/n)"
+- **NO ejecutar rollback automáticamente — siempre requiere confirmación explícita.**
+- Si el usuario confirma rollback: ejecutar el comando de rollback del provider.
+
+Si los logs están limpios: continuar.
+
+## Paso 10 — Smoke tests (condicional)
+
+Si `project.yaml` → `deploy.smoke_tests` está definido y tiene URLs:
+
+Para cada URL de smoke test:
+```
+curl -s -o /dev/null -w "%{http_code}" <url>
+```
+
+- Si el código HTTP es 2xx: marcar como pasado.
+- Si el código HTTP es 4xx o 5xx: reportar fallo.
+
+Si algún smoke test falla:
+- Reportar qué URL falló y el código HTTP
+- Sugerir rollback: "¿Querés hacer rollback? (s/n)"
+- **NO ejecutar rollback automáticamente.**
+
+Si todos pasan o no hay smoke tests definidos: continuar.
+
+---
+
+## Al terminar exitosamente
+
+Obtener la URL de producción de `project.yaml` → `deploy.production_url` o del output del provider.
+
+Reportar: "Deploy exitoso. URL: [production_url]"
+
+Agregar entrada al daily note si existe `docs/daily-notes/` (buscar el archivo del día actual):
+```
+## Deploy
+- Fecha: YYYY-MM-DD HH:MM
+- Estado: exitoso
+- URL: [production_url]
+```
+
+---
+
+## Si hay errores en cualquier paso
+
+Reportar claramente:
+- En qué paso ocurrió el error
+- Qué salió mal (con logs si están disponibles)
+- Qué acción correctiva se sugiere
+
+**Nunca continuar automáticamente después de un error de deploy.** Siempre esperar confirmación explícita del usuario antes de cualquier acción de remediación.

package/assets/adapters/claude-code/commands/wiki-ingest.md

@@ -0,0 +1,7 @@
+# wiki-ingest
+
+Ingest a source into the project wiki.
+
+Use the wiki-ingest skill to process: $ARGUMENTS
+
+If $ARGUMENTS is empty, ask the user for the source (URL, file path, or text to ingest).

package/assets/adapters/claude-code/commands/wiki-lint.md

@@ -0,0 +1,5 @@
+# wiki-lint
+
+Run a health check on the project wiki: verify index integrity, find broken links, detect orphan pages, and auto-repair what's safe to fix.
+
+Use the wiki-lint skill now. Report all issues found and list what was auto-repaired vs what needs manual attention.

package/assets/adapters/claude-code/commands/wiki-query.md

@@ -0,0 +1,7 @@
+# wiki-query
+
+Query the project wiki and answer with citations.
+
+Use the wiki-query skill to answer: $ARGUMENTS
+
+If $ARGUMENTS is empty, ask the user what they want to look up in the wiki.