@cristiancorreau/forge 2.9.4 → 2.9.6

package/assets/adapters/claude-code/commands/new-feature.md

@@ -1,11 +1,16 @@
 # new-feature
 
+> **Atajo de orquestación.** Este comando NO es un flujo competidor: es un wrapper que delega
+> en el pipeline SDD canónico `/plan` → `/work` → `/review` → `/ship`. Usa el mismo template de
+> spec (`core/templates/spec-template.md`) y la misma máquina de estados
+> (`DRAFT` → `REVIEW` → `APPROVED` → `IMPLEMENTED`). No dupliques aquí lógica de esos comandos:
+> invocá cada uno en su etapa.
+
 Inicia la implementación de una nueva feature siguiendo SDD (Spec-Driven Development).
 
 Argumentos: $ARGUMENTS — nombre de la feature o ruta a la spec existente.
 
-1. Si no existe spec para "$ARGUMENTS" en docs/specs/, crearla primero antes de escribir código.
-2. Leer la spec antes de proponer cualquier implementación.
-3. Proponer el plan de implementación y esperar aprobación explícita.
-4. Implementar con tests junto a la implementación, no al final.
-5. Al terminar, actualizar la spec con las decisiones tomadas durante la implementación.
+1. **Spec** — Si no existe spec para "$ARGUMENTS" en `docs/specs/`, ejecutar `/plan <fase> "$ARGUMENTS"` para crearla (queda en `APPROVED`). Si ya existe, leerla.
+2. **Implementación** — Ejecutar `/work` para implementar la spec aprobada. Propone el team, espera aprobación e implementa con tests junto a la implementación, no al final. `/work` marca la spec como `IMPLEMENTED` y completa "Notas de implementación".
+3. **Review** — Ejecutar `/review` para obtener el veredicto vinculante (persiste en `.claude/review-status.json`).
+4. **Ship** — Si el review resultó `APPROVED` y el usuario lo pide, ejecutar `/ship` para el deploy.

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

@@ -16,44 +16,66 @@ 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:
+Crear el archivo con el template canónico de `core/templates/spec-template.md` (misma fuente única de verdad que el skill `spec`):
 
 ```markdown
-# Spec: <título>
-**Fase:** <fase> | **Estado:** draft | **Fecha:** YYYY-MM-DD
+# <fase> Título de la Feature
 
-## Problem statement
-[¿Qué problema resuelve? ¿Por qué ahora?]
+> Estado: DRAFT | REVIEW | APPROVED | IMPLEMENTED
+> Responsable: [nombre o rol]
+> Creada: YYYY-MM-DD | Actualizada: YYYY-MM-DD
 
-## Non-goals
-[Qué NO cubre esta spec]
+## Contexto
 
-## Acceptance criteria
-- [ ] Criterio 1 (verificable, testeable)
-- [ ] Criterio 2
+Por qué existe esta feature. Qué problema resuelve. Qué pasa si no la hacemos.
 
-## Compliance mapping
-[Si el proyecto tiene frameworks de compliance en project.yaml, mapear qué artículos aplican. Si no aplica, escribir "N/A".]
+## Decisión
 
-## Edge cases
-[Casos límite que la implementación debe manejar]
+Qué vamos a implementar exactamente. Ser específico: endpoints, tablas, componentes.
 
-## Implementation notes
-[Se llena durante la implementación]
+## Alternativas consideradas
 
-## Decisiones tomadas
-[Se llena durante la implementación]
+| Opción | Pros | Contras | Descartada por |
+|--------|------|---------|----------------|
+| Opción A | ... | ... | ... |
+| Opción B | ... | ... | ... |
+
+## Criterios de aceptación
+
+- [ ] Criterio verificable 1
+- [ ] Criterio verificable 2
+- [ ] Criterio verificable N
+
+## Impacto de compliance
+
+Si el proyecto tiene `compliance.frameworks` configurado, completar:
+
+- **Ley 21.719**: art. X → [descripción del impacto]
+- **GDPR**: Art. Y → [descripción del impacto]
+- No aplica (si no hay impacto de compliance)
+
+## Dependencias
+
+- Requiere que [otra spec ID] esté implementada
+- Bloqueada por [issue/ticket]
+
+## Notas de implementación
+
+Cualquier decisión tomada durante la implementación que no estaba en la spec original.
 ```
 
+Marcar el estado inicial como `DRAFT` (la primera línea del bloque de metadata: `> Estado: DRAFT`).
+
 ### 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)"
+1. **Contexto**: "¿Qué problema concreto resuelve esta feature? ¿Por qué ahora y no más adelante? ¿Qué pasa si no la hacemos?"
+2. **Decisión**: "¿Qué vamos a implementar exactamente? Ser específico: endpoints, tablas, componentes."
+3. **Alternativas consideradas**: "¿Qué otras opciones se evaluaron y por qué se descartaron?"
+4. **Criterios de aceptación**: "¿Cuáles son los criterios de aceptación verificables? (cada uno debe ser testeable de forma objetiva)"
+5. Si `project.yaml` tiene frameworks de compliance: "¿Qué artículos o controles de compliance aplican a esta feature?"
+6. **Dependencias**: "¿De qué otras specs o tickets depende esta feature?"
 
 Completar el archivo con las respuestas del usuario a medida que avanza.
 
@@ -68,28 +90,31 @@ Leer `project.yaml` → `project.mode`:
 **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 criterios de aceptación 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?
+- ¿El contexto y la decisión son suficientemente específicos para evitar scope creep?
+- ¿Faltan dependencias o alternativas relevantes que deberían documentarse?
 
-Mostrar las críticas como bullet points. Preguntar: "¿Ajustamos la spec antes de marcarla como ready?"
+Mostrar las críticas como bullet points. Preguntar: "¿Ajustamos la spec antes de pasarla a REVIEW?"
 
 Si el usuario ajusta: actualizar el archivo y repetir el Critic una vez más.
 
-### Paso 5 — Marcar como ready
+### Paso 5 — Marcar como APPROVED
 
 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."
+- Cambiar `> Estado: DRAFT` → `> Estado: APPROVED` en el archivo
+- Actualizar la fecha de `Actualizada:` a la fecha de hoy
+- Confirmar: "Spec aprobada: `docs/specs/<archivo>.md`. Ahora podés ejecutar `/work` para implementarla."
+
+> Estados de spec (alineados con `core/templates/spec-template.md`): `DRAFT` → `REVIEW` → `APPROVED` → `IMPLEMENTED`. `/plan` crea en `DRAFT` y aprueba a `APPROVED`; `/work` la marca `IMPLEMENTED`.
 
 ---
 
 ## Modo listar (`/plan` sin argumentos)
 
-Buscar todos los archivos `.md` en `docs/specs/` que contengan `**Estado:** draft` o `**Estado:** in-review`.
+Buscar todos los archivos `.md` en `docs/specs/` que contengan `> Estado: DRAFT` o `> Estado: REVIEW`.
 
-Si no hay ninguno: "No hay specs en estado draft o in-review. Ejecutá `/plan <fase> \"<título>\"` para crear una."
+Si no hay ninguno: "No hay specs en estado DRAFT o REVIEW. Ejecutá `/plan <fase> \"<título>\"` para crear una."
 
 Si hay alguno: mostrarlos como lista numerada con título, fase y fecha. Ejemplo:
 ```
@@ -106,10 +131,10 @@ Preguntar: "¿Cuál continuamos?"
 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?
+- ¿Los criterios de aceptación son objetivamente testeables?
+- ¿Hay ambigüedades en el contexto, la decisión o los criterios?
+- ¿Las alternativas consideradas justifican la decisión tomada?
+- ¿Las dependencias están completas y son explícitas?
 
 Mostrar sugerencias de mejora como bullet points con la sección específica que afectan.
 

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

@@ -15,7 +15,7 @@ Ejecutar los siguientes comandos y guardar sus resultados:
 ## 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 existe `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

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

@@ -10,10 +10,12 @@ Leer `project.yaml`. Si no existe sección `deploy`: "deploy no configurado en p
 
 ## Paso 1 — Verificar review
 
-Buscar en el contexto de la sesión si se ejecutó `/review` y resultó en APPROVED.
+Leer `.claude/review-status.json` (es el archivo que persiste `/review` en su Paso 6).
 
-- Si hay evidencia de review aprobado: continuar.
-- Si no hay evidencia: "¿Confirmás que el código fue revisado y aprobado? (s/n)"
+- **Si el archivo existe**: parsear su contenido y validar el campo `verdict`.
+  - `verdict == "APPROVED"`: continuar. (Opcional: si el `timestamp` del review es anterior al último commit relevante, advertir que el review podría estar desactualizado y pedir confirmación.)
+  - `verdict == "CHANGES_REQUESTED"` o `verdict == "BLOCKED"`: "El último review resultó en `<verdict>`. Resolvé los puntos y volvé a ejecutar `/review` antes de hacer deploy." y detener.
+- **Si el archivo NO existe** (fallback): "No se encontró `.claude/review-status.json`. ¿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
@@ -31,7 +33,7 @@ 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 todos pasan: ejecutar `gh pr merge --merge`
 
 Si no: continuar sin mergear.
 

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

@@ -6,11 +6,11 @@ Scope: $ARGUMENTS (ej: `--serial`, `--autorun`, o vacío para modo paralelo est
 
 ## Paso 1 — Identificar la spec
 
-Buscar archivos `.md` en `docs/specs/` que contengan `**Estado:** ready`.
+Buscar archivos `.md` en `docs/specs/` que contengan `> Estado: APPROVED`.
 
 - 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.
+- Si no hay ninguna: "No hay spec en estado APPROVED. Ejecutá `/plan` primero." y detener.
 
 Leer la spec seleccionada completa antes de continuar.
 
@@ -94,8 +94,10 @@ Si hay errores o conflictos: reportar claramente y preguntar cómo proceder. No
 
 ## 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
+Estados de spec (alineados con `core/templates/spec-template.md`): `DRAFT` → `REVIEW` → `APPROVED` → `IMPLEMENTED`.
 
-Confirmar: "Implementación completa. Spec actualizada a `implemented`. Podés ejecutar `/review` y luego `/ship`."
+- Al completar exitosamente: cambiar `> Estado: APPROVED` → `> Estado: IMPLEMENTED`
+- Actualizar la fecha de `Actualizada:` a la fecha de hoy
+- Completar la sección "Notas de implementación" con lo que se hizo y las decisiones tomadas
+
+Confirmar: "Implementación completa. Spec actualizada a `IMPLEMENTED`. Podés ejecutar `/review` y luego `/ship`."

package/assets/core/agents/backend-engineer.md

@@ -54,8 +54,8 @@ Implementás el backend del proyecto. Tu scope está definido en el `project.yam
 - `/review` para revisar tu propio trabajo antes de reportar al orchestrator
 
 **Hooks que aplican a tu trabajo:**
-- `pre-edit-check.py`: te va a advertir si dejás `console.log` o credenciales en código
+- `pre-edit-check.js`: te va a advertir si dejás `console.log` o credenciales en código
 - `post-turn-check.sh`: correrá typecheck sobre los archivos que modificaste
-- `pre-bash-check.py` (en proyectos standard/enterprise): bloquea comandos destructivos en producción — si necesitás hacer algo en producción, coordiná con el humano explícitamente
+- `pre-bash-check.js` (en proyectos standard/enterprise): bloquea comandos destructivos en producción — si necesitás hacer algo en producción, coordiná con el humano explícitamente
 
-**Scope:** Operar solo en los directorios de tu scope (ver `scope:` en el frontmatter de este agente). No tocar archivos de frontend o mobile sin autorización explícita.
+**Scope:** Operar solo en el directorio de backend del proyecto (el derivado de `stack.backend` en `project.yaml`, o `paths.api` si está definido). No tocar archivos de frontend o mobile sin autorización explícita.

package/assets/core/agents/compliance-reviewer.md

@@ -79,5 +79,5 @@ Este agente opera sobre el conocimiento de entrenamiento del modelo, **no sobre
 - ¿Hay logs de auditoría para las acciones del PR?
 
 **Hooks relacionados:**
-- En mode=enterprise existe `compliance-pre-edit.py` que detecta patrones peligrosos antes de que edites
-- Si ves que ese hook no está activo, notificar al equipo
+- Los hooks de guardrail instalados (`pre-edit-check.js`, `pre-bash-check.js`) detectan secrets, debug y comandos destructivos antes de que se editen archivos
+- Si el proyecto define un hook de compliance adicional (ej: detección de PII en logs) y no está activo, notificar al equipo

package/assets/core/agents/docs-writer.md

@@ -72,6 +72,6 @@ Si aplica: qué artículos o secciones de las leyes relevantes toca esta feature
 - No editar manualmente — son el registro de sesión
 
 **Wiki (docs/wiki/):**
-- index.md: actualizar con `/forge wiki ingest`
+- index.md: actualizar con el skill `/wiki-ingest` (consultas con `/wiki-query`, validación con `/wiki-lint`)
 - log.md: append-only — nunca editar entradas pasadas
 - raw/: fuentes originales inmutables

package/assets/core/agents/frontend-engineer.md

@@ -63,8 +63,8 @@ Implementás el frontend del proyecto. Tu scope está definido en el `project.ya
 - `/review` para revisar tu propio trabajo antes de reportar al orchestrator
 
 **Hooks que aplican a tu trabajo:**
-- `pre-edit-check.py`: detecta `console.log` en TypeScript y credenciales hardcodeadas — corregí antes de reportar listo
+- `pre-edit-check.js`: detecta `console.log` en TypeScript y credenciales hardcodeadas — corregí antes de reportar listo
 - `post-turn-check.sh`: correrá `tsc` sobre los archivos que modificaste — asegurate de que typechecks pasan
-- `pre-bash-check.py` (en proyectos standard/enterprise): bloquea comandos destructivos en producción
+- `pre-bash-check.js` (en proyectos standard/enterprise): bloquea comandos destructivos en producción
 
 **Scope:** Operar solo en archivos de UI y componentes (ver `stack.frontend` en `project.yaml`). No tocar archivos de backend, API ni base de datos sin autorización explícita del orchestrator.

package/assets/core/agents/orchestrator.md

@@ -16,7 +16,7 @@ Sos el lead de un agent team. Tu trabajo es coordinar, no implementar.
 1. **Recibir tareas** del humano y entenderlas en profundidad.
 2. **Identificar la spec** correspondiente en `docs/specs/`. Si no existe, parar y pedir que se cree.
 3. **Descomponer la tarea** en sub-tareas independientes que distintos agentes puedan tomar en paralelo.
-4. **Spawnear el team** con los agentes apropiados (ver roster en AGENTS.md del proyecto).
+4. **Spawnear el team** con los agentes apropiados. El roster se descubre desde `.claude/agents/*.md` (o el `AGENTS.md` que `forge init` genera en la raíz del proyecto; si no existe, usá los agentes instalados en `.claude/agents/`).
 5. **Sintetizar** los resultados al final y reportar al humano.
 
 ## Cómo spawnear agentes
@@ -40,6 +40,8 @@ Agent({
 
 ### Coordinación con SendMessage
 
+`SendMessage` e `isolation: "worktree"` son capacidades del runtime de teams — no necesitan declararse en el campo `tools:` del frontmatter.
+
 ```
 SendMessage({ to: "backend-engineer", message: "Tipos listos. Podés continuar." })
 ```
@@ -71,12 +73,12 @@ Esperá aprobación antes de spawnear el team.
 
 ## Reglas
 
-- Leé `CLAUDE.md` y `AGENTS.md` raíz antes de spawnear cualquier agente.
+- Leé `CLAUDE.md` raíz y, si existe, `AGENTS.md` (generado por `forge init`) antes de spawnear cualquier agente.
 - Sin spec en `docs/specs/` → no empieces. Pedí que se cree primero.
 - Mínimo número de agentes que la tarea justifica. <3 archivos → un solo agente basta.
 - Incluí al `compliance-reviewer` si la tarea toca datos de usuarios, consentimientos o logs.
 - Pedí aprobación al humano antes de mergear cuando >5 archivos del mismo módulo fueron tocados.
-- Máximo 3 agentes simultáneos en suscripción Pro / hasta 7-8 con Max 20x o API directa.
+- **Techo de paralelismo (concurrentes):** máximo 3 agentes simultáneos en suscripción Pro / hasta 7-8 con Max 20x o API directa. Este es el único límite de agentes concurrentes.
 
 ## No hagas
 
@@ -95,10 +97,10 @@ Esperá aprobación antes de spawnear el team.
 **Reglas obligatorias para el team:**
 1. Nunca delegues implementación sin spec aprobada en `docs/specs/`
 2. El team no edita código en main — verificar branch antes de spawnear teammates
-3. Máximo 5-6 tasks por teammate, 3-5 teammates por sesión
+3. Como guía de carga: ~5-6 tasks por teammate y 3-5 teammates totales por sesión (el techo de *concurrencia* es el de la sección Reglas: 3 Pro / 7-8 Max)
 4. Si el proyecto es enterprise: incluir compliance-reviewer en PRs que toquen datos de usuarios
 
 **Hooks activos que el team debe respetar:**
-- `pre-edit-check.py`: bloquea edits en main y detecta credenciales hardcodeadas
+- `pre-edit-check.js`: bloquea edits en main y detecta credenciales hardcodeadas
 - `post-turn-check.sh`: corre typecheck al terminar cada turno
-- `pre-bash-check.py` (si mode=standard/enterprise): bloquea comandos destructivos en producción
+- `pre-bash-check.js` (si mode=standard/enterprise): bloquea comandos destructivos en producción

package/assets/core/agents/security-auditor.md

@@ -50,5 +50,5 @@ con severidad y recomendación de fix.
 **Checklist adicional para Forge v2:**
 - ¿El PR agrega variables de entorno? Verificar que están documentadas en `.env.example`
 - ¿Hay cambios en permisos de `settings.json`? Revisar que el allow-list es mínimo necesario
-- ¿Los hooks de producción están activos? (pre-bash-check.py para mode=standard/enterprise)
+- ¿Los hooks de producción están activos? (pre-bash-check.js para mode=standard/enterprise)
 - ¿El deploy pipeline de `/ship` incluye verificación de runtime logs?

package/assets/core/agents/test-engineer.md

@@ -25,7 +25,7 @@ testeable, se lo pedís al agente que corresponda y esperás.
 - **No escribís código de producción.** Si algo no se puede testear, lo reportás.
 - Tests determinísticos — sin `Math.random()` ni `Date.now()` sin mockear.
 - Nombres descriptivos: `describe("cuando X") / it("debería Y")`.
-- Tests de integración deben usar base de datos real, no mocks del ORM.
+- Cuando el proyecto tiene base de datos (según `stack` en `project.yaml`), los tests de integración deben usar una instancia real (o un contenedor efímero), no mocks del ORM.
 - Limpiar fixtures después de cada test (transacciones o truncate).
 - Sin `console.log` en tests — el runner lo reportará como falla en CI.
 

package/assets/core/skills/README.md

@@ -31,7 +31,7 @@ wiki-lint   → health check + auto-reparación
 | `security-audit` | Universal | No | new-feature, security-auditor |
 | `db-migrate` | Universal | No (solo el ORM del proyecto) | new-feature |
 | `browser-test` | Universal | `agent-browser` CLI (npm i -g) | new-feature, usuario directo |
-| `wiki-ingest` | Wiki | No | usuario directo, docs-writer |
+| `wiki-ingest` | Wiki | No | usuario directo, agente docs-writer |
 | `wiki-query` | Wiki | No | usuario directo, new-feature |
 | `wiki-lint` | Wiki | No | usuario directo |
 | `local2prod` | Universal | CLI del provider de deploy | new-feature |
@@ -53,7 +53,7 @@ Configurar en `project.yaml` bajo `skills.active`:
 - **`new-feature`**: checklist completo de implementación (orquesta los otros)
 
 ### Wiki — knowledge base del proyecto
-Configurar en `project.yaml` bajo `skills.active`. Generan slash commands `/wiki-ingest`, `/wiki-query`, `/wiki-lint` en Claude Code. La estructura `docs/wiki/` se inicializa con `forge-init.py`:
+Configurar en `project.yaml` bajo `skills`. Generan slash commands `/wiki-ingest`, `/wiki-query`, `/wiki-lint` en Claude Code. La estructura `wiki/` se inicializa con `forge wiki ingest <archivo>`:
 - **`wiki-ingest`**: ingesta fuentes (URL, archivo, texto) → actualiza `raw/` + páginas wiki + index + log
 - **`wiki-query`**: responde preguntas usando el wiki como base, con citas a páginas
 - **`wiki-lint`**: verifica integridad del wiki: links, huérfanos, frontmatter, log

package/assets/core/skills/aitmpl-search/SKILL.md

@@ -1,8 +1,7 @@
 # Skill: aitmpl-search
 
 Busca en el catálogo curado de forge: frameworks de agentes IA, MCP servers instalables,
-profiles de stack y herramientas. La búsqueda es offline (catálogo local); opcionalmente
-puede extenderse a GitHub con `--github`.
+profiles de stack y herramientas. La búsqueda es offline (catálogo local).
 
 Triggers: /aitmpl-search, "buscar templates", "buscar en catálogo", "templates de AI",
 "buscar template", "buscar MCP", "buscar profile".
@@ -24,33 +23,22 @@ Triggers: /aitmpl-search, "buscar templates", "buscar en catálogo", "templates
 
 Búsqueda por texto en el catálogo local:
 ```bash
-python3 .agentic/scripts/aitmpl-search.py "<query>" --limit 10
+forge aitmpl-search "<query>" --limit 10
 ```
 
-Filtrar por categoría (`framework`, `mcp-server`, `profile`, `tool`, `resource`):
+Filtrar por categoría (`mcp-server`, `framework`, `profile`):
 ```bash
-python3 .agentic/scripts/aitmpl-search.py "<query>" --category mcp-server
+forge aitmpl-search --category mcp-server
 ```
 
 Ver todas las categorías disponibles:
 ```bash
-python3 .agentic/scripts/aitmpl-search.py --list-categories
+forge aitmpl-search --list-categories
 ```
 
 Salida JSON (para integración o análisis):
 ```bash
-python3 .agentic/scripts/aitmpl-search.py "<query>" --json
-```
-
-Extender con búsqueda en GitHub (requiere red; límite 60 req/h sin token):
-```bash
-python3 .agentic/scripts/aitmpl-search.py "<query>" --github
-export GITHUB_TOKEN=ghp_...   # aumenta a 5000 req/h
-```
-
-Desde el CLI interactivo:
-```bash
-python3 .agentic/forge.py   # → "Buscar templates" → buscar o filtrar por categoría
+forge aitmpl-search "<query>" --json
 ```
 
 ### Paso 2 — Analizar resultados
@@ -71,4 +59,4 @@ Para profiles, ofrece agregar el profile a `project.yaml` directamente.
 
 - No asumir que un resultado del catálogo está actualizado — verificar el repositorio antes de recomendar
 - No crear agentes Tier 2 sin revisar si el stack ya tiene un profile en `profiles/`
-- No instalar MCP servers sin verificar que el usuario tiene Python 3.9+ y las dependencias requeridas
+- No instalar MCP servers sin verificar que el usuario tiene las dependencias requeridas

package/assets/core/skills/local2prod/SKILL.md

@@ -27,7 +27,7 @@ git status                      # confirmar qué va al commit
 
 git commit -m "tipo(scope): descripción en imperativo
 
-Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>"
+Co-Authored-By: <modelo> <noreply@anthropic.com>"
 ```
 
 Si ya hay un commit listo, ir directo al Paso 2.

package/assets/core/skills/new-feature/SKILL.md

@@ -117,7 +117,7 @@ Invocar el skill `/security-audit` como checklist mental antes de escribir cualq
    # > Estado: IMPLEMENTED
    ```
 
-5. **Actualizar CLAUDE.md** — mover el ID de spec de "En curso" a "Completadas"
+6. **Actualizar CLAUDE.md** — mover el ID de spec de "En curso" a "Completadas"
 
 ---
 

package/assets/core/skills/phase-kickoff/SKILL.md

@@ -3,6 +3,8 @@
 Protocolo para iniciar una nueva fase de desarrollo en un proyecto forge.
 Activar al comienzo de cada sprint o fase nueva.
 
+Triggers: /phase-kickoff, "iniciar sprint", "kickoff de fase", "empezar fase"
+
 ---
 
 ## Cuándo usar este skill

package/assets/core/skills/spec/SKILL.md

@@ -3,6 +3,8 @@
 Redactar specs de features siguiendo la plantilla del framework forge.
 Activar antes de escribir cualquier spec nueva.
 
+Triggers: /spec, "crear spec", "redactar spec", "nueva spec"
+
 ---
 
 ## Cuándo usar este skill

package/assets/core/skills/wiki-ingest/SKILL.md

@@ -33,7 +33,7 @@ Si es texto   → usar el texto tal como está
 ### Paso 2 — Almacenar en raw/ (inmutable)
 
 ```
-Path: docs/wiki/raw/<tema>/<YYYY-MM-DD>-<slug-del-titulo>.md
+Path: wiki/raw/<tema>/<YYYY-MM-DD>-<slug-del-titulo>.md
 
 Formato del archivo raw:
 ---
@@ -59,14 +59,14 @@ Leer el contenido y identificar:
 ### Paso 4 — Actualizar páginas wiki
 
 Para cada concepto identificado:
-- Si `docs/wiki/concepts/<nombre>.md` existe → agregar sección con nueva info + citar fuente
+- Si `wiki/concepts/<nombre>.md` existe → agregar sección con nueva info + citar fuente
 - Si no existe → crear la página desde la plantilla
 
 Para cada entidad identificada:
-- Si `docs/wiki/entities/<nombre>.md` existe → actualizar con nueva info
+- Si `wiki/entities/<nombre>.md` existe → actualizar con nueva info
 - Si no existe → crear la página desde la plantilla
 
-Crear siempre `docs/wiki/sources/<slug>.md` con resumen de la fuente:
+Crear siempre `wiki/sources/<slug>.md` con resumen de la fuente:
 
 ```markdown
 ---
@@ -95,11 +95,11 @@ tags: [tag1, tag2]
 
 ### Paso 5 — Actualizar index.md y log.md
 
-En `docs/wiki/index.md`:
+En `wiki/index.md`:
 - Agregar filas nuevas en las tablas correspondientes (concepts, entities, sources)
 - Si la categoría no existe, crearla
 
-En `docs/wiki/log.md` (append-only — NUNCA editar entradas anteriores):
+En `wiki/log.md` (append-only — NUNCA editar entradas anteriores):
 
 ```markdown
 ## [<YYYY-MM-DD>] ingest | <título de la fuente>
@@ -180,4 +180,4 @@ Si la nueva fuente contradice algo en el wiki:
 
 - `wiki-query` consume las páginas que este skill crea
 - `wiki-lint` verifica la integridad después de un ingest
-- `docs-writer` puede invocar wiki-ingest al documentar una decisión nueva
+- el agente `docs-writer` (no es un skill) puede invocar wiki-ingest al documentar una decisión nueva

package/assets/core/skills/wiki-lint/SKILL.md

@@ -20,7 +20,7 @@ wiki", "wiki health", "wiki check".
 
 ### 1. Integridad del índice
 
-Leer `docs/wiki/index.md` y verificar:
+Leer `wiki/index.md` y verificar:
 
 ```
 ✓ Cada [[link]] del índice apunta a un archivo que existe
@@ -32,10 +32,10 @@ Auto-reparar: agregar al índice los archivos que faltan (con descripción vací
 ### 2. Wikilinks rotos
 
 Buscar en todas las páginas wiki referencias `[[ruta/nombre]]` y verificar que
-el archivo `docs/wiki/ruta/nombre.md` existe.
+el archivo `wiki/ruta/nombre.md` existe.
 
 ```bash
-grep -rn "\[\[" docs/wiki/ --include="*.md" | grep -v "raw/"
+grep -rn "\[\[" wiki/ --include="*.md" | grep -v "raw/"
 ```
 
 Reportar: lista de links rotos con el archivo donde aparecen.
@@ -53,7 +53,7 @@ Reportar: lista de huérfanas. No auto-borrar — requiere decisión humana.
 
 ### 4. Integridad del log
 
-Verificar que `docs/wiki/log.md` existe y tiene al menos una entrada.
+Verificar que `wiki/log.md` existe y tiene al menos una entrada.
 El log es append-only — nunca modificar entradas pasadas.
 
 Reportar si el log no ha sido actualizado en los últimos 30 días (wiki posiblemente abandonado).

package/assets/core/skills/wiki-query/SKILL.md

@@ -22,9 +22,9 @@ sabemos de", "wiki:", "query:", "consultar wiki", "what does the wiki say about"
 
 ### Paso 1 — Leer el índice
 
-Leer `docs/wiki/index.md` para identificar qué páginas son relevantes a la pregunta.
+Leer `wiki/index.md` para identificar qué páginas son relevantes a la pregunta.
 
-Si no hay wiki (`docs/wiki/` no existe o está vacío): indicar que el wiki está vacío
+Si no hay wiki (`wiki/` no existe o está vacío): indicar que el wiki está vacío
 y sugerir usar `/wiki-ingest` para agregar conocimiento.
 
 ### Paso 2 — Leer páginas relevantes
@@ -60,7 +60,7 @@ qué fuentes ingestar para cubrir el gap.
 Si la pregunta produjo una síntesis nueva (no trivial, reutilizable), archivarla:
 
 ```
-docs/wiki/synthesis/<tema>.md
+wiki/synthesis/<tema>.md
 ```
 
 Formato:

package/assets/profiles/astro/agents/frontend-engineer.md

@@ -5,6 +5,7 @@ model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: astro
+last_verified: "2026-06"
 ---
 
 # Frontend Engineer — Astro
@@ -15,7 +16,7 @@ ni backend fuera de las integraciones de Astro.
 
 ## Stack
 
-- **Framework:** Astro 4.x
+- **Framework:** Astro (última versión estable)
 - **Rendering:** SSG por defecto; SSR con adaptadores (Vercel, Cloudflare, Node)
 - **UI Islands:** React, Svelte, Vue o Lit según el proyecto
 - **Contenido:** MDX, Content Collections, Markdown
@@ -36,7 +37,7 @@ ni backend fuera de las integraciones de Astro.
 
 - **Sin JavaScript innecesario:** Astro carga 0 JS por defecto — mantenerlo así salvo islands explícitas.
 - **Content Collections tipadas:** toda colección define su schema Zod en `src/content/config.ts`.
-- **Sin secrets en el cliente:** variables de entorno con `VITE_` prefix son públicas — solo usarlas para config no sensible.
+- **Sin secrets en el cliente:** variables de entorno con prefijo `PUBLIC_` son públicas (`import.meta.env.PUBLIC_*`) — solo usarlas para config no sensible.
 - **Accesibilidad:** HTML semántico, atributos `alt`, roles ARIA cuando el HTML no es suficiente.
 - **Sin spec, sin código:** la spec debe existir en `docs/specs/` antes de implementar.
 
@@ -66,7 +67,7 @@ Antes de tocar cualquier archivo, verificar que existe una spec en `docs/specs/`
 Este agente puede invocar los slash commands definidos en `.claude/commands/` del proyecto. Revisar qué comandos están disponibles con `/help` antes de empezar.
 
 ### Hooks activos en este stack
-- **`pre-edit-check.py`**: se ejecuta antes de cada edición y bloquea debug statements en archivos `.astro`, `.ts` y `.tsx`. No dejes `console.log`, `debugger` ni comentarios `// TODO` sin ticket.
+- **`pre-edit-check.js`**: se ejecuta antes de cada edición y bloquea debug statements en archivos `.astro`, `.ts` y `.tsx`. No dejes `console.log`, `debugger` ni comentarios `// TODO` sin ticket.
 - **`post-turn-check.sh`**: se ejecuta al terminar cada turno. Verifica que `astro build` no tenga errores de TypeScript ni warnings de compilación.
 
 ### Reglas de scope

package/assets/profiles/django/agents/api-engineer.md

@@ -1,10 +1,11 @@
 ---
 name: api-engineer
-description: "Implementa el backend del proyecto. Django 4.x/5.x + DRF/Django Ninja + PostgreSQL. Scope: apps/ y config/."
+description: "Implementa el backend del proyecto. Django (última versión estable) + DRF/Django Ninja + PostgreSQL. Scope: apps/ y config/."
 model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: django
+last_verified: "2026-06"
 ---
 
 # API Engineer — Django
@@ -14,7 +15,7 @@ Implementás el backend del proyecto. Tu scope es `apps/` y `config/` (estructur
 ## Stack
 
 - **Runtime:** Python 3.11+
-- **Framework:** Django 4.x / 5.x. NO usar Flask ni FastAPI.
+- **Framework:** Django (última versión estable, preferir la LTS vigente). NO usar Flask ni FastAPI.
 - **API:** Django REST Framework (DRF) con ViewSets y Routers, o Django Ninja para APIs tipadas. No mezcles los dos en el mismo proyecto.
 - **ORM:** Django ORM. NO usar queries raw salvo en migraciones de datos complejas.
 - **Migraciones:** `manage.py makemigrations` + `manage.py migrate`. Un concepto por migración; nombres descriptivos.

package/assets/profiles/expo/agents/mobile-engineer.md

@@ -5,6 +5,7 @@ model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: expo
+last_verified: "2026-06"
 ---
 
 # Mobile Engineer — Expo SDK
@@ -23,7 +24,7 @@ Leé ese archivo antes de empezar.
 
 ## Reglas
 
-1. **Bundle size controlado:** iOS <200KB, Android <250KB por defecto. Verificar con `expo bundle-size`.
+1. **Bundle size controlado:** iOS <200KB, Android <250KB por defecto. Verificar con `npx expo export` + análisis del output (o `source-map-explorer`) y `npx expo-doctor`.
 2. **API idiomática:** exponer la funcionalidad como hooks React (`useConsent()`, `useFeature()`).
 3. **No mezclar APIs nativas y JS bridge en el mismo flujo.** Si necesitás algo nativo, va en su propio módulo aislado.
 4. **Permisos explícitos:** no solicitar permisos antes de que el usuario entienda por qué.
@@ -61,7 +62,7 @@ Antes de tocar cualquier archivo, verificar que existe una spec en `docs/specs/`
 Este agente puede invocar los slash commands definidos en `.claude/commands/` del proyecto. Revisar qué comandos están disponibles con `/help` antes de empezar.
 
 ### Hooks activos en este stack
-- **`pre-edit-check.py`**: se ejecuta antes de cada edición. Detecta debug statements (`console.log`, `debugger`) en archivos `.ts` y `.tsx`.
+- **`pre-edit-check.js`**: se ejecuta antes de cada edición. Detecta debug statements (`console.log`, `debugger`) en archivos `.ts` y `.tsx`.
 - **`post-turn-check.sh`**: se ejecuta al terminar cada turno. Corre `tsc --noEmit` para verificar TypeScript estricto. El proyecto usa `strict: true` — cualquier error de tipos bloquea el turno. Corregir antes de reportar al orchestrator.
 
 ### Reglas de scope

package/assets/profiles/express/agents/api-engineer.md

@@ -5,6 +5,7 @@ model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: express
+last_verified: "2026-06"
 ---
 
 # API Engineer — Express + Node.js

package/assets/profiles/fastapi/agents/api-engineer.md

@@ -5,6 +5,7 @@ model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: fastapi
+last_verified: "2026-06"
 ---
 
 # API Engineer — FastAPI
@@ -77,8 +78,8 @@ El proyecto puede tener slash commands en `.claude/commands/`. Revisarlos antes
 
 ### Hooks activos en este stack
 
-- **`pre-edit-check.py`** (PreToolUse/Edit|Write): detecta `print()` en archivos `.py` que no sean scripts de forge ni archivos en `.agentic/`. En FastAPI, usar `logging` en lugar de `print()` para toda salida de diagnóstico. Además bloquea secrets hardcodeados y protege la rama `main`.
-- **`pre-bash-check.py`** (PreToolUse/Bash): bloquea comandos destructivos en producción. Detecta `alembic downgrade base` y `DROP TABLE` si el contexto apunta a producción.
+- **`pre-edit-check.js`** (PreToolUse/Edit|Write): detecta `print()` en archivos `.py` que no sean scripts de forge ni archivos en `.agentic/`. En FastAPI, usar `logging` en lugar de `print()` para toda salida de diagnóstico. Además bloquea secrets hardcodeados y protege la rama `main`.
+- **`pre-bash-check.js`** (PreToolUse/Bash): bloquea comandos destructivos en producción. Detecta `alembic downgrade base` y `DROP TABLE` si el contexto apunta a producción.
 
 ### Reglas de scope
 

package/assets/profiles/go-gin/agents/api-engineer.md

@@ -5,6 +5,7 @@ model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: go-gin
+last_verified: "2026-06"
 ---
 
 # API Engineer — Go + Gin

package/assets/profiles/hono-drizzle/agents/api-engineer.md

@@ -5,6 +5,7 @@ model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: hono-drizzle
+last_verified: "2026-06"
 ---
 
 # API Engineer — Hono + Drizzle
@@ -72,8 +73,8 @@ El proyecto puede tener slash commands en `.claude/commands/`. Revisarlos antes
 
 ### Hooks activos en este stack
 
-- **`pre-bash-check.py`** (PreToolUse/Bash): bloquea `prisma migrate reset` y otros comandos destructivos en contexto de producción. **Crítico para Drizzle:** también detecta `drizzle-kit push` sin bandera `--force` en producción.
-- **`pre-edit-check.py`** (PreToolUse/Edit|Write): detecta `console.log` y `debugger` en archivos `.ts`/`.tsx`, bloquea secrets hardcodeados, y protege la rama `main`.
+- **`pre-bash-check.js`** (PreToolUse/Bash): bloquea `prisma migrate reset` y otros comandos destructivos en contexto de producción. **Crítico para Drizzle:** también detecta `drizzle-kit push` sin bandera `--force` en producción.
+- **`pre-edit-check.js`** (PreToolUse/Edit|Write): detecta `console.log` y `debugger` en archivos `.ts`/`.tsx`, bloquea secrets hardcodeados, y protege la rama `main`.
 
 ### Reglas de scope
 

package/assets/profiles/laravel/agents/api-engineer.md

@@ -1,10 +1,11 @@
 ---
 name: api-engineer
-description: "Implementa el backend del proyecto. Laravel 10+ + Sanctum/Passport + PostgreSQL/MySQL. Scope: app/ y routes/api.php."
+description: "Implementa el backend del proyecto. Laravel (última versión estable) + Sanctum/Passport + PostgreSQL/MySQL. Scope: app/ y routes/api.php."
 model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: laravel
+last_verified: "2026-06"
 ---
 
 # API Engineer — Laravel
@@ -14,7 +15,7 @@ Implementás el backend del proyecto. Tu scope es `app/` y `routes/api.php`. Le
 ## Stack
 
 - **Runtime:** PHP 8.2+
-- **Framework:** Laravel 10, 11 o 12. NO usar Lumen ni micro-frameworks.
+- **Framework:** Laravel (última versión estable). NO usar Lumen ni micro-frameworks.
 - **API:** Laravel Resources + ResourceCollections para transformación de respuestas. Form Requests para validación.
 - **ORM:** Eloquent. Sin queries raw salvo en migraciones de datos o reportes complejos con `DB::select()` + parámetros.
 - **Migraciones:** `artisan make:migration` + `artisan migrate`. Un concepto por migración; nombres descriptivos en snake_case.
@@ -104,8 +105,8 @@ El proyecto puede tener slash commands en `.claude/commands/`. Revisarlos antes
 
 ### Hooks activos en este stack
 
-- **`pre-edit-check.py`** (PreToolUse/Edit|Write): detecta patrones de debug PHP (`var_dump()`, `dd()`, `print_r()`) en archivos `.php`, bloquea secrets hardcodeados, y protege la rama `main`. Relevante en controladores y modelos Eloquent donde `dd()` se usa frecuentemente en desarrollo.
-- **`pre-bash-check.py`** (PreToolUse/Bash): bloquea comandos destructivos en producción. Detecta `php artisan migrate:reset` y `php artisan migrate:fresh` si el contexto de producción está activo.
+- **`pre-edit-check.js`** (PreToolUse/Edit|Write): detecta patrones de debug PHP (`var_dump()`, `dd()`, `print_r()`) en archivos `.php`, bloquea secrets hardcodeados, y protege la rama `main`. Relevante en controladores y modelos Eloquent donde `dd()` se usa frecuentemente en desarrollo.
+- **`pre-bash-check.js`** (PreToolUse/Bash): bloquea comandos destructivos en producción. Detecta `php artisan migrate:reset` y `php artisan migrate:fresh` si el contexto de producción está activo.
 
 ### Reglas de scope
 

package/assets/profiles/laravel/agents/fullstack-engineer.md

@@ -5,6 +5,7 @@ model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: laravel
+last_verified: "2026-06"
 ---
 
 # Fullstack Engineer — Laravel
@@ -14,7 +15,7 @@ Implementás features full-stack en el proyecto Laravel. Tu scope es `app/`, `re
 ## Stack
 
 - **Runtime:** PHP 8.2+
-- **Framework:** Laravel 10, 11 o 12.
+- **Framework:** Laravel (última versión estable).
 - **Frontend:** Blade + Livewire 3 por defecto. Si el proyecto usa Inertia.js (Vue 3 o React), el `CLAUDE.md` lo indicará.
 - **Estilos:** Tailwind CSS. Sin Bootstrap salvo que el proyecto lo establezca.
 - **Auth:** Laravel Breeze (simple) o Jetstream (equipos + 2FA). No reinventar autenticación.

package/assets/profiles/laravel/agents/migration-specialist.md

@@ -5,6 +5,7 @@ model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: laravel
+last_verified: "2026-06"
 ---
 
 # Migration Specialist — Laravel

package/assets/profiles/nestjs/agents/api-engineer.md

@@ -5,6 +5,7 @@ model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: nestjs
+last_verified: "2026-06"
 ---
 
 # API Engineer — NestJS
@@ -15,7 +16,7 @@ Leé ese archivo antes de empezar.
 ## Stack
 
 - **Runtime:** Node.js 20 LTS.
-- **Framework:** NestJS 10+. Arquitectura modular: un módulo por dominio.
+- **Framework:** NestJS (última versión estable). Arquitectura modular: un módulo por dominio.
 - **ORM:** Prisma (preferido) o TypeORM con decoradores. NO usar query builders ad-hoc.
 - **Validación:** class-validator + class-transformer en DTOs. Usar `ValidationPipe` global.
 - **Autenticación:** `@nestjs/passport` + JWT. Guards para proteger rutas.

package/assets/profiles/nextjs-admin/agents/admin-engineer.md

@@ -1,13 +1,14 @@
 ---
 name: admin-engineer
-description: Construye el dashboard de administración del proyecto con Next.js 15 + shadcn/ui. NO trabaja fuera del directorio de admin definido en project.yaml.
+description: Construye el dashboard de administración del proyecto con Next.js (última versión estable) + shadcn/ui. NO trabaja fuera del directorio de admin definido en project.yaml.
 model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: nextjs-admin
+last_verified: "2026-06"
 ---
 
-# Admin Engineer — Next.js 15 + shadcn/ui
+# Admin Engineer — Next.js (última versión estable) + shadcn/ui
 
 Construís el dashboard de administración del proyecto. Tu scope es el directorio de admin
 definido en el `CLAUDE.md` del proyecto (típicamente `packages/admin/` o `apps/admin/`).
@@ -15,7 +16,7 @@ Leé ese archivo antes de empezar.
 
 ## Stack
 
-- **Framework:** Next.js 15 con App Router.
+- **Framework:** Next.js (última versión estable) con App Router.
 - **UI:** shadcn/ui + Tailwind 4. NO Tailwind 3, NO Material UI, NO Chakra, NO Mantine.
 - **Forms:** React Hook Form + Zod.
 - **Estado servidor:** TanStack Query. NO SWR, NO useEffect para fetch.
@@ -68,8 +69,8 @@ El proyecto puede tener slash commands en `.claude/commands/`. Revisarlos antes
 
 ### Hooks activos en este stack
 
-- **`pre-edit-check.py`** (PreToolUse/Edit|Write): detecta `console.log` y `debugger` en archivos `.ts`/`.tsx`, bloquea secrets hardcodeados, y protege la rama `main`. Especialmente relevante en componentes React donde los `console.log` de debug son comunes.
-- **`pre-bash-check.py`** (PreToolUse/Bash): bloquea comandos destructivos en producción. Aplica si el proyecto usa Prisma como ORM (detecta `prisma migrate reset`).
+- **`pre-edit-check.js`** (PreToolUse/Edit|Write): detecta `console.log` y `debugger` en archivos `.ts`/`.tsx`, bloquea secrets hardcodeados, y protege la rama `main`. Especialmente relevante en componentes React donde los `console.log` de debug son comunes.
+- **`pre-bash-check.js`** (PreToolUse/Bash): bloquea comandos destructivos en producción. Aplica si el proyecto usa Prisma como ORM (detecta `prisma migrate reset`).
 
 ### Reglas de scope
 

package/assets/profiles/playwright-crawler/agents/scanner-engineer.md

@@ -5,6 +5,7 @@ model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: playwright-crawler
+last_verified: "2026-06"
 ---
 
 # Scanner Engineer — Playwright + BullMQ

package/assets/profiles/rails/agents/fullstack-engineer.md

@@ -5,6 +5,7 @@ model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: rails
+last_verified: "2026-06"
 ---
 
 # Fullstack Engineer — Ruby on Rails
@@ -14,7 +15,7 @@ proyecto Rails (app/, db/, config/, spec/). Leé el `CLAUDE.md` del proyecto ant
 
 ## Stack
 
-- **Framework:** Ruby on Rails 7.x o 8.x.
+- **Framework:** Ruby on Rails (última versión estable).
 - **Base de datos:** PostgreSQL. Sin SQLite en producción.
 - **Frontend:** Hotwire (Turbo + Stimulus) por defecto. Si el proyecto usa React/Vue, el `CLAUDE.md` lo indicará.
 - **Tests:** RSpec + FactoryBot + Shoulda Matchers. Capybara para tests de sistema.

package/assets/profiles/sveltekit/agents/frontend-engineer.md

@@ -5,6 +5,7 @@ model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: sveltekit
+last_verified: "2026-06"
 ---
 
 # Frontend Engineer — SvelteKit

package/assets/profiles/vuenuxt/agents/frontend-engineer.md

@@ -1,19 +1,20 @@
 ---
 name: frontend-engineer
-description: "Construye apps con Nuxt 3 + Vue 3 Composition API + Pinia + TypeScript. Scope: app/ o src/ (páginas, componentes, composables, stores)."
+description: "Construye apps con Nuxt (última versión estable) + Vue 3 Composition API + Pinia + TypeScript. Scope: app/ o src/ (páginas, componentes, composables, stores)."
 model: sonnet
 tools: Read, Grep, Glob, Bash, Edit, Write
 tier: 2
 profile: vuenuxt
+last_verified: "2026-06"
 ---
 
 # Frontend Engineer — Vue/Nuxt
 
-Construís aplicaciones con Nuxt 3 y Vue 3. Tu scope es `app/` o `src/` según cómo esté configurado el proyecto. Leé el `CLAUDE.md` del proyecto antes de empezar.
+Construís aplicaciones con Nuxt (última versión estable) y Vue 3. Tu scope es `app/` o `src/` según cómo esté configurado el proyecto. Leé el `CLAUDE.md` del proyecto antes de empezar.
 
 ## Stack
 
-- **Framework:** Nuxt 3 (última versión estable). NO usar Nuxt 2 ni Vue 2.
+- **Framework:** Nuxt (última versión estable). NO usar Nuxt 2 ni Vue 2.
 - **UI:** Vue 3 con Composition API (`<script setup>`). NO usar Options API salvo en componentes heredados que no se pueden migrar.
 - **State:** Pinia para estado global. Composables con `ref`/`computed` para estado local.
 - **Routing:** File-based routing de Nuxt (`pages/`). No usar vue-router directamente salvo para configuración avanzada en `nuxt.config.ts`.

package/assets/profiles/wordpress/agents/divi-engineer.md

@@ -259,7 +259,7 @@ Antes de tocar cualquier archivo, verificar que existe una spec en `docs/specs/`
 Este agente puede invocar los slash commands definidos en `.claude/commands/` del proyecto. Revisar qué comandos están disponibles con `/help` antes de empezar.
 
 ### Hooks activos en este stack
-- **`pre-edit-check.py`**: se ejecuta antes de cada edición. Detecta patrones de debug PHP (`var_dump()`, `print_r()`, `error_log()`) en archivos `.php` del child theme y módulos personalizados.
+- **`pre-edit-check.js`**: se ejecuta antes de cada edición. Detecta patrones de debug PHP (`var_dump()`, `print_r()`, `error_log()`) en archivos `.php` del child theme y módulos personalizados.
 - **`post-turn-check.sh`**: se ejecuta al terminar cada turno. Verifica que no haya residuos de debug y que el child theme esté activo (`wp theme status`).
 
 ### APIs de terceros y seguridad

package/assets/profiles/wordpress/agents/elementor-engineer.md

@@ -14,8 +14,8 @@ Diseñás e implementás sitios con Elementor Free y Elementor Pro. Tu scope inc
 
 ## Stack
 
-- **WordPress:** 6.4+.
-- **Elementor Free:** última versión estable (4.x).
+- **WordPress:** última versión estable.
+- **Elementor Free:** última versión estable (serie 3.x).
 - **Elementor Pro:** última versión estable (requerido para Theme Builder, Dynamic Tags, Loop Grid, Popup Builder, Form Builder).
 - **PHP:** 8.1+.
 - **Child theme:** obligatorio. Nunca modificar el parent theme directamente.
@@ -295,7 +295,7 @@ Antes de tocar cualquier archivo, verificar que existe una spec en `docs/specs/`
 Este agente puede invocar los slash commands definidos en `.claude/commands/` del proyecto. Revisar qué comandos están disponibles con `/help` antes de empezar.
 
 ### Hooks activos en este stack
-- **`pre-edit-check.py`**: se ejecuta antes de cada edición. Detecta patrones de debug PHP (`var_dump()`, `print_r()`, `error_log()`) en archivos `.php` del child theme, widgets personalizados y dynamic tags.
+- **`pre-edit-check.js`**: se ejecuta antes de cada edición. Detecta patrones de debug PHP (`var_dump()`, `print_r()`, `error_log()`) en archivos `.php` del child theme, widgets personalizados y dynamic tags.
 - **`post-turn-check.sh`**: se ejecuta al terminar cada turno. Verifica que el CSS de Elementor esté regenerado (`wp elementor flush-css`) si se modificaron archivos de estilo.
 
 ### APIs de terceros y seguridad

package/assets/profiles/wordpress/agents/wp-engineer.md

@@ -14,7 +14,7 @@ Implementás features en WordPress usando las APIs modernas del core. Tu scope e
 
 ## Stack
 
-- **WordPress:** 6.4+ (Full Site Editing disponible desde 6.0, iA activa desde 6.4).
+- **WordPress:** última versión estable (Full Site Editing desde 6.0). Verificar con `wp core version`.
 - **PHP:** 8.1+. Sin código legacy con `mysql_*` ni funciones deprecadas.
 - **Editor:** Gutenberg / Block Editor. Sin Classic Editor salvo que el `CLAUDE.md` lo exija.
 - **Bloques:** `@wordpress/create-block` para scaffolding. Bloques dinámicos con PHP render callback cuando el contenido es dinámico.
@@ -202,7 +202,7 @@ Antes de tocar cualquier archivo, verificar que existe una spec en `docs/specs/`
 Este agente puede invocar los slash commands definidos en `.claude/commands/` del proyecto. Revisar qué comandos están disponibles con `/help` antes de empezar.
 
 ### Hooks activos en este stack
-- **`pre-edit-check.py`**: se ejecuta antes de cada edición. Detecta patrones de debug PHP (`var_dump()`, `print_r()`, `error_log()`) en archivos `.php`. Estos nunca deben llegar a producción.
+- **`pre-edit-check.js`**: se ejecuta antes de cada edición. Detecta patrones de debug PHP (`var_dump()`, `print_r()`, `error_log()`) en archivos `.php`. Estos nunca deben llegar a producción.
 - **`post-turn-check.sh`**: se ejecuta al terminar cada turno. Corre `composer test` (PHPUnit) y `./vendor/bin/phpcs --standard=WordPress` si están configurados. Corregir errores antes de reportar.
 
 ### APIs de terceros y seguridad

package/dist/commands/init.js

@@ -410,7 +410,7 @@ export async function init(args) {
                         ...allAgents.map(a => `.claude/agents/${a}.md`),
                     ];
                     const ts = new Date().toISOString();
-                    saveManifest(projectRoot, buildManifest(runtime, installedFiles, projectRoot, '2.9.4', ts));
+                    saveManifest(projectRoot, buildManifest(runtime, installedFiles, projectRoot, '2.9.6', ts));
                 },
             },
         ]);

package/dist/version.d.ts

@@ -1,3 +1,3 @@
 /** Single source of truth for the CLI version (kept in sync with package.json). */
-export declare const VERSION = "2.9.4";
+export declare const VERSION = "2.9.6";
 //# sourceMappingURL=version.d.ts.map

package/dist/version.js

@@ -1,3 +1,3 @@
 /** Single source of truth for the CLI version (kept in sync with package.json). */
-export const VERSION = '2.9.4';
+export const VERSION = '2.9.6';
 //# sourceMappingURL=version.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@cristiancorreau/forge",
-  "version": "2.9.4",
+  "version": "2.9.6",
   "description": "Agentic development framework — multi-runtime support for Claude Code, OpenCode, Codex and Kiro",
   "author": "Cristian Correa <cristian@socialweb.cl>",
   "license": "Apache-2.0",
@@ -28,7 +28,7 @@
     "build:all": "npm run build:assets && npm run build",
     "dev": "tsc --watch",
     "prepublishOnly": "npm run build:all",
-    "test": "node --test test/commands.test.mjs"
+    "test": "node --test test/commands.test.mjs test/assets.test.mjs"
   },
   "files": [
     "dist",