@liriraid/agentflow-ai 1.0.10

package/templates/es/.claude/skills/orchestrator-openspec/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: orchestrator-openspec
+description: >
+  Abre, crea o actualiza artefactos de OpenSpec para cambios grandes o de varias fases.
+license: MIT
+metadata:
+  owner: agentflow
+  version: "0.1"
+---
+
+# Skill: orchestrator-openspec
+
+Trigger: "crea un change", "abre openspec", "haz proposal", "haz spec", "haz design", "prepara tasks del cambio"
+
+## Propósito
+
+Usar `openspec/` como capa persistente para cambios relevantes antes de delegar implementación al motor.
+
+## Cuándo usar esta skill
+
+- Cuando el cambio tiene varias fases o varios agentes
+- Cuando el usuario pide proposal, spec, design o tasks explícitamente
+- Cuando el cambio es lo bastante grande para no dejarlo solo en conversación
+- Cuando hace falta mantener trazabilidad durable del cambio
+
+## Reglas críticas
+
+- Si no existe un change para el trabajo actual, crea uno en `openspec/changes/<change-name>/`.
+- Usa nombres de change claros, en kebab-case y alineados con el objetivo del usuario.
+- Usa `openspec/FLOW.md` como guía de fases y criterio de avance.
+- Mantén consistencia entre:
+  - `proposal.md`
+  - `specs/spec.md`
+  - `design.md`
+  - `tasks.md`
+  - `verify-report.md`
+- Mantén `.openspec.yaml` actualizado con `status`, `current_phase` y `queue_synced` cuando el change evolucione.
+- `tasks.md` debe poder traducirse luego a `QUEUE.md`.
+- No llenes `QUEUE.md` de implementación grande sin haber aterrizado primero el cambio en OpenSpec cuando el trabajo lo justifique.
+- Si el cambio es pequeño y directo, no fuerces OpenSpec innecesariamente.
+
+## Flujo recomendado
+
+1. Definir o confirmar el `change-name`
+2. Crear el change con `npm run openspec:new -- <change-name>` si no existe
+3. Completar o actualizar `proposal.md`
+4. Completar o actualizar `specs/spec.md`
+5. Completar o actualizar `design.md` si el cambio lo requiere
+6. Completar o actualizar `tasks.md`
+7. Convertir las tareas listas en entradas concretas para `QUEUE.md`
+8. Actualizar `verify-report.md` y `archive-report.md` cuando el cambio madure o cierre
+
+## Resultado esperado
+
+Un change de OpenSpec coherente, reutilizable y listo para alimentar el flujo de delegación del orquestador.

package/templates/es/.claude/skills/orchestrator-propose/SKILL.md

@@ -0,0 +1,33 @@
+---
+name: orchestrator-propose
+description: >
+  Crea o actualiza la propuesta inicial de un cambio grande antes de delegar implementación.
+  Trigger: "haz proposal", "crea propuesta", "propone este cambio", "documenta el alcance"
+license: MIT
+metadata:
+  owner: agentflow
+  version: "1.0"
+---
+
+# Skill: orchestrator-propose
+
+## Propósito
+
+Crear la propuesta base del cambio para que el orquestador tenga claro qué se quiere hacer, por qué y con qué alcance.
+
+## Reglas críticas
+
+- Lee primero el contexto del usuario, `ORCHESTRATOR.md`, `QUEUE.md` y `openspec/FLOW.md` si existe.
+- Si el cambio aún no tiene `change-name`, propón uno en kebab-case claro y estable.
+- Crea o actualiza `openspec/changes/<change-name>/proposal.md`.
+- La propuesta debe dejar claro:
+  - objetivo
+  - alcance
+  - restricciones
+  - riesgos iniciales
+  - qué no entra en este cambio
+- Si el cambio es pequeño y directo, no fuerces una propuesta demasiado larga.
+
+## Resultado esperado
+
+Una propuesta clara que permita pasar a spec o design sin ambigüedad.

package/templates/es/.claude/skills/orchestrator-queue-planning/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: orchestrator-queue-planning
+description: >
+  Convierte contexto y hallazgos en tareas concretas para QUEUE.md, con prioridades, agente objetivo y dependencias claras.
+  Trigger: "crea tareas", "planifica en queue", "divide el trabajo", "delegar tareas", "llenar queue"
+license: MIT
+metadata:
+  owner: agentflow
+  version: "0.1"
+---
+
+# Orchestrator Queue Planning
+
+## Propósito
+
+Traducir una necesidad del usuario o hallazgos de exploración en tareas concretas para el motor del orquestador.
+
+## Reglas críticas
+
+- Escribe TASKs pequeñas, concretas y ejecutables.
+- Cada tarea debe tener agente, prioridad, repo y descripción clara.
+- Usa dependencias `> after:TASK-NNN` cuando una tarea no pueda arrancar todavía.
+- Prioriza mantener ocupados los agentes permitidos por defecto sin inventar trabajo fuera del alcance.
+- Si el trabajo es exploratorio, usa primero `OpenCode`; si es ejecución estructurada, reparte según el dominio.
+- Cuando haya 3 o más tareas independientes, intenta crear una primera tanda con al menos una TASK para un Claude-Worker (`Backend` o `Frontend`), una para `Codex` y una para `OpenCode`.
+- `OpenCode` puede implementar código cuando la tarea esté clara; no lo limites a lectura o auditoría si la cola necesita ejecución.
+- Codex puede trabajar en `repo=frontend`, pero con menor permisividad: úsalo para apoyo acotado y verificable; deja los cambios amplios de FE al agente `Frontend` de Claude.
+- Si Codex u OpenCode fallan por cuota, tokens, rate limit o indisponibilidad persistente, crea o reasigna una TASK de fallback a un Claude-Worker.
+- Si existe un `openspec/changes/<change-name>/tasks.md`, usa ese archivo como fuente de verdad para traducirlo a `QUEUE.md`.
+- No sobrecargues una sola IA con demasiadas tareas si puedes paralelizar sin riesgo.
+- Mantén `QUEUE.md` coherente con el objetivo actual del usuario.
+
+## Resultado esperado
+
+Una cola clara y accionable que el motor pueda despachar de inmediato.

package/templates/es/.claude/skills/orchestrator-spec/SKILL.md

@@ -0,0 +1,28 @@
+---
+name: orchestrator-spec
+description: >
+  Crea o actualiza la especificación funcional del cambio con requerimientos y escenarios.
+  Trigger: "haz spec", "crea especificación", "documenta requerimientos", "define escenarios"
+license: MIT
+metadata:
+  owner: agentflow
+  version: "1.0"
+---
+
+# Skill: orchestrator-spec
+
+## Propósito
+
+Traducir la propuesta del cambio en una especificación clara para que la implementación y la verificación tengan una referencia estable.
+
+## Reglas críticas
+
+- Lee la propuesta antes de escribir la spec.
+- Crea o actualiza `openspec/changes/<change-name>/specs/spec.md`.
+- Expresa requerimientos y escenarios de forma verificable.
+- No mezcles demasiado diseño técnico dentro de la spec salvo que sea necesario para entender el comportamiento.
+- Si faltan datos del usuario, deja explícitas las suposiciones.
+
+## Resultado esperado
+
+Una spec que permita pasar a design, tasks o verify sin depender de la conversación.

package/templates/es/.claude/skills/orchestrator-tasks/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: orchestrator-tasks
+description: >
+  Descompone un cambio en tareas de implementación concretas y listas para traducirse a QUEUE.md.
+  Trigger: "haz tasks", "descompón el cambio", "crea tareas del cambio", "plan de tareas"
+license: MIT
+metadata:
+  owner: agentflow
+  version: "1.0"
+---
+
+# Skill: orchestrator-tasks
+
+## Propósito
+
+Convertir la propuesta, la spec y el diseño en tareas claras que el orquestador pueda delegar a agentes concretos.
+
+## Reglas críticas
+
+- Lee propuesta, spec y design antes de escribir tareas.
+- Crea o actualiza `openspec/changes/<change-name>/tasks.md`.
+- Las tareas deben ser:
+  - pequeñas
+  - delegables
+  - ordenables
+  - entendibles por un agente sin contexto infinito
+- Marca si `tasks.md` ya fue traducido a `QUEUE.md`.
+- Si el usuario quiere ejecución inmediata, el siguiente paso natural es `orchestrator-queue-planning`.
+
+## Resultado esperado
+
+Una lista de tareas lista para convertirse en cola viva del motor.

package/templates/es/.claude/skills/orchestrator-verify/SKILL.md

@@ -0,0 +1,31 @@
+---
+name: orchestrator-verify
+description: >
+  Verifica que la implementación realmente cumpla la propuesta, la spec, el diseño y las tareas definidas.
+  Trigger: "verifica", "valida el cambio", "review contra spec", "confirma la implementación"
+license: MIT
+metadata:
+  owner: agentflow
+  version: "1.0"
+---
+
+# Skill: orchestrator-verify
+
+## Propósito
+
+Validar que lo implementado coincide con lo que el orquestador planeó y que Claude lo puede aceptar con criterio.
+
+## Reglas críticas
+
+- Lee proposal, spec, design, tasks y el estado real de implementación.
+- Crea o actualiza `openspec/changes/<change-name>/verify-report.md`.
+- Clasifica hallazgos como:
+  - crítico
+  - advertencia
+  - sugerencia
+- Si el resultado no está alineado, no lo cierres como correcto.
+- Claude debe seguir siendo quien valida si el resultado coincide con lo pedido en la task.
+
+## Resultado esperado
+
+Un verify-report útil para decidir si el cambio se acepta, se corrige o se archiva.

package/templates/es/.codex/README.md

@@ -0,0 +1,7 @@
+# Codex Local Config
+
+Esta carpeta reserva la configuración local del proyecto para Codex.
+
+- hoy se usa como base reusable del proyecto
+- mañana puede alojar prompts, perfiles, reglas o plugins locales
+- no debe depender solo de configuración global del usuario

package/templates/es/.opencode/README.md

@@ -0,0 +1,7 @@
+# OpenCode Local Config
+
+Esta carpeta reserva la configuración local del proyecto para OpenCode.
+
+- hoy se usa como base reusable del proyecto
+- mañana puede alojar reglas, prompts o convenciones específicas
+- no debe depender solo de configuración global del usuario

package/templates/es/AGENT-CONFIG.md

@@ -0,0 +1,83 @@
+# Agent Config
+
+Este archivo define la capa de configuración por agente del orquestador reusable.
+
+## Objetivo
+
+Separar dos niveles:
+
+1. **Runtime config**
+   Vive en `orchestrator.config.json` bajo `agents` y `repos`.
+   Controla qué agentes puede lanzar el motor y cómo se conectan a los repos.
+
+2. **Agent profile config**
+   Vive en `orchestrator.config.json` bajo `agentProfiles`.
+   Controla cómo se organiza la configuración local por CLI o familia de agente.
+
+Esto permite:
+
+- usar solo 1 agente
+- usar 3 agentes como base (`claude`, `codex`, `opencode`)
+- o escalar a más agentes sin rediseñar el config
+
+## Regla de diseño
+
+- `agents` = instancias operativas visibles para el motor
+- `agentProfiles` = configuración reusable por tipo de agente
+
+Ejemplo:
+
+- `Backend` y `Frontend` pueden compartir el profile `claude`
+- `Codex` usa el profile `codex`
+- `OpenCode` usa el profile `opencode`
+
+## Claude-Orquestador vs Claude-Worker
+
+El profile `claude` puede aparecer en dos formas operativas:
+
+- **Claude-Orquestador**: sesión interactiva que lee `ORCHESTRATOR.md`, mantiene `QUEUE.md`, delega y revisa.
+- **Claude-Worker**: agentes como `Backend` y `Frontend`, lanzados por la TUI, que sí pueden implementar código cuando tienen una TASK asignada.
+
+La sesión orquestadora no modifica el repo real directamente. Si Claude debe trabajar en código, se le asigna una TASK a `Backend` o `Frontend`.
+
+Cuando haya varias tareas independientes, el reparto recomendado es mantener ocupados a `Claude-Worker`, `Codex` y `OpenCode` en paralelo antes de acumular varias tareas en un solo agente.
+
+## Campos sugeridos de `agentProfiles`
+
+| Campo                 | Requerido | Propósito                                  |
+| --------------------- | --------- | ------------------------------------------ |
+| `enabled`             | No        | Si este profile está activo en el proyecto |
+| `localConfigDir`      | No        | Carpeta local del proyecto para ese agente |
+| `skillsDir`           | No        | Carpeta local de skills si aplica          |
+| `primary`             | No        | Si es el agente principal del flujo        |
+| `useForOrchestration` | No        | Si puede actuar como orquestador           |
+| `notes`               | No        | Notas o restricciones operativas           |
+
+## Convención inicial
+
+Para este proyecto reusable:
+
+- `claude` es el profile principal
+- `codex` y `opencode` son profiles de apoyo
+- otros profiles pueden existir, aunque no estén habilitados por defecto
+
+## Directorios locales sugeridos
+
+- `.claude/`
+- `.codex/`
+- `.opencode/`
+
+Estos directorios no tienen que ser iguales a los del home del usuario. Son la capa local del proyecto.
+
+## Prioridad
+
+Si existe configuración global del agente en el home del usuario y también una local del proyecto:
+
+- la local del proyecto debe ganar en el flujo del orquestador reusable
+
+## Relación con skills
+
+- `Claude` usa `.claude/skills/` como base principal del proyecto
+- `Codex` y `OpenCode` pueden tener configuración local propia aunque hoy no usen el mismo modelo de skills
+- `OpenCode` no es solo auditor: puede explorar, auditar e implementar cuando la TASK esté clara
+- el diseño debe permitir que mañana también tengan una capa local más rica

package/templates/es/CLAUDE.md

@@ -0,0 +1,136 @@
+# Claude Project Routing
+
+Este archivo define cómo **Claude Code** debe comportarse dentro de este repo y qué skills locales debe priorizar.
+
+## Prioridad de resolución
+
+1. Prioriza siempre las skills locales de este repo en `./.claude/skills/`
+2. Usa `.atl/skill-registry.md` como catálogo de skills del proyecto
+3. Usa `ENGRAM.md` como convención local para memoria persistente
+4. No dependas de `~/.claude/skills/` para el flujo principal del orquestador
+5. Si existe una skill global con el mismo nombre, la **local** del proyecto gana
+6. Si existe `openspec/`, úsalo como capa persistente para cambios grandes antes de delegar implementación amplia
+
+## Routing automático de intención -> skill
+
+### Inicio del orquestador
+
+Si el usuario dice algo como:
+
+- `lee ORCHESTRATOR.md y arranca`
+- `arranca el orquestador`
+- `inicia el orquestador`
+- `start orchestrator`
+
+usa la skill:
+
+- `orchestrator-init`
+
+### Exploración / análisis / investigación
+
+Si el usuario dice algo como:
+
+- `explora este proyecto`
+- `analiza estos archivos`
+- `investiga este flujo`
+- `revisa esto antes de implementar`
+
+usa la skill:
+
+- `orchestrator-explore`
+
+### Proposal / spec / design / tasks
+
+Si el usuario dice algo como:
+
+- `haz proposal`
+- `haz spec`
+- `haz design`
+- `haz tasks`
+- `documentemos este cambio`
+- `prepara el cambio antes de implementarlo`
+
+usa la skill:
+
+- `orchestrator-propose`
+- `orchestrator-spec`
+- `orchestrator-design`
+- `orchestrator-tasks`
+
+### Planificación de cola / delegación
+
+Si el usuario dice algo como:
+
+- `crea tareas`
+- `divide el trabajo`
+- `llena la queue`
+- `deleguemos esto`
+- `planifica las tasks`
+
+usa la skill:
+
+- `orchestrator-queue-planning`
+
+### OpenSpec / cambios grandes
+
+Si el usuario dice algo como:
+
+- `crea un change`
+- `abre openspec`
+- `documentemos este cambio antes de implementarlo`
+
+usa la skill:
+
+- `orchestrator-openspec`
+
+### Apply / verify / archive
+
+Si el usuario dice algo como:
+
+- `implementa este cambio`
+- `aplica las tareas`
+- `verifica la implementación`
+- `archiva el cambio`
+
+usa la skill:
+
+- `orchestrator-apply`
+- `orchestrator-verify`
+- `orchestrator-archive`
+
+### Memoria / continuidad / recordatorios
+
+Si el usuario dice algo como:
+
+- `recuerda qué hicimos`
+- `cómo quedó esto`
+- `guarda este contexto`
+- `haz un resumen de sesión`
+- `trae el contexto anterior`
+
+usa la skill:
+
+- `orchestrator-memory`
+
+## Reglas operativas
+
+- Si hay ambigüedad entre explorar y planificar, explora primero.
+- Si el usuario pide iniciar sesión del orquestador, arranca con `orchestrator-init` antes de cualquier otra cosa.
+- Si el trabajo es grande, multifase o involucra varios agentes, pasa por `orchestrator-propose` / `orchestrator-spec` / `orchestrator-design` / `orchestrator-tasks` antes de llenar `QUEUE.md`.
+- Si una exploración ya produjo suficiente contexto, el siguiente paso natural es `orchestrator-propose` o `orchestrator-tasks`, según el nivel de claridad.
+- Si el usuario pide continuidad o recordar trabajo previo, usa `orchestrator-memory`.
+- Si el usuario pide proposal/spec/design/tasks de un cambio, usa las skills `orchestrator-*` correspondientes.
+- Mantén la lógica del orquestador alineada con `ORCHESTRATOR.md`.
+- Mantén la memoria alineada con `ENGRAM.md`.
+- Respeta las restricciones de agentes por defecto del proyecto.
+
+## Archivos clave
+
+- `ORCHESTRATOR.md` — rol y reglas del orquestador
+- `ENGRAM.md` — convención local de memoria persistente
+- `.atl/skill-registry.md` — catálogo local de skills
+- `.claude/skills/*/SKILL.md` — skills locales del proyecto
+- `docs/components.md` — mapa de componentes implementados
+- `docs/usage.md` — flujo recomendado de uso
+- `openspec/` — artefactos persistentes para cambios grandes
+- `QUEUE.md` — cola activa del motor

package/templates/es/ENGRAM.md

@@ -0,0 +1,70 @@
+# Engram Memory Convention
+
+Este archivo define cómo usar **Engram** dentro de este proyecto para no depender solo del contexto corto de sesión.
+
+## Objetivo
+
+Guardar y recuperar:
+
+- decisiones de arquitectura
+- hallazgos de exploración
+- bugs y su causa raíz
+- preferencias del usuario
+- estado de cambios importantes
+- resúmenes de sesión
+
+## Reglas de uso
+
+### Al iniciar una sesión del orquestador
+
+- Busca memoria reciente del proyecto antes de asumir que todo empieza desde cero.
+- Si existe contexto anterior relevante, úsalo para no repetir exploración innecesaria.
+- Si el usuario menciona “recuerda”, “qué hicimos” o “cómo quedó”, consulta primero Engram.
+
+### Durante el trabajo
+
+Guarda en Engram cuando ocurra cualquiera de estas cosas:
+
+- una decisión importante
+- un hallazgo técnico no obvio
+- una convención nueva
+- un bug con causa identificada
+- un cambio de flujo del orquestador
+- una preferencia explícita del usuario
+
+### Al terminar la sesión
+
+- Guarda un resumen de sesión con lo hecho, lo descubierto y lo que sigue.
+- El objetivo es que la próxima sesión no empiece ciega.
+
+## Topic keys recomendados
+
+- `orchestrator/session-summary`
+- `orchestrator/routing`
+- `orchestrator/skills`
+- `orchestrator/engram`
+- `orchestrator/tui`
+- `orchestrator/queue-workflow`
+
+Para cambios por feature:
+
+- `feature/<nombre-del-cambio>`
+- `bug/<nombre-del-bug>`
+- `decision/<tema>`
+
+## Regla de prioridad
+
+- Usa Engram como memoria persistente.
+- Usa `.atl/skill-registry.md` como catálogo local de skills.
+- Usa `ORCHESTRATOR.md` y `CLAUDE.md` como reglas activas del proyecto.
+
+## Importante
+
+Engram es una ayuda para continuidad, no reemplaza:
+
+- `QUEUE.md`
+- `ORCHESTRATOR.md`
+- `handoffs/`
+- el estado visible en la TUI
+
+La memoria debe complementar el flujo del orquestador, no ocultarlo.