@liriraid/agentflow-ai 1.0.28 → 1.0.29

package/bin/agentflow.mjs

@@ -18,7 +18,6 @@ const TEMPLATE_PATHS = [
 	'ENGRAM.md',
 	'AGENT-CONFIG.md',
 	'PROJECT.md',
-	'.atl',
 	'docs',
 	'orchestrator.config.json',
 	'QUEUE.md',

package/package.json

@@ -1,64 +1,65 @@
-{
-  "name": "@liriraid/agentflow-ai",
-  "version": "1.0.28",
-  "description": "Multi-agent workspace orchestrator with TUI. Coordinates AI coding agents over your real frontend and backend projects.",
-  "author": "LiriRaid",
-  "homepage": "https://github.com/LiriRaid/agentflow-ai#readme",
-  "repository": {
-    "type": "git",
-    "url": "git+https://github.com/LiriRaid/agentflow-ai.git"
-  },
-  "bugs": {
-    "url": "https://github.com/LiriRaid/agentflow-ai/issues"
-  },
-  "publishConfig": {
-    "access": "public"
-  },
-  "main": "orchestrator.js",
-  "bin": {
-    "agentflow": "bin/agentflow.mjs"
-  },
-  "files": [
-    "bin",
-    "src",
-    "templates",
-    "orchestrator.js",
-    "LICENSE",
-    "README.md"
-  ],
-  "engines": {
-    "node": ">=18.0.0"
-  },
-  "keywords": [
-    "ai",
-    "agents",
-    "orchestrator",
-    "agentflow-ai",
-    "claude",
-    "codex",
-    "gemini",
-    "cursor",
-    "opencode",
-    "abacus",
-    "tui",
-    "multi-agent",
-    "coding-assistant",
-    "openspec",
-    "engram",
-    "skills",
-    "agent-config"
-  ],
-  "license": "MIT",
-  "dependencies": {
-    "blessed": "^0.1.81",
-    "ink": "^5.2.1",
-    "react": "^18.3.1"
-  },
-  "scripts": {
-    "start": "node orchestrator.js",
-    "start:paused": "node orchestrator.js --paused",
-    "start:ink": "node src/ink/index.mjs",
-    "start:ink:paused": "node src/ink/index.mjs --paused",
-    "cli:help": "node bin/agentflow.mjs --help"
-  }
-}
+{
+  "name": "@liriraid/agentflow-ai",
+  "version": "1.0.29",
+  "description": "Multi-agent workspace orchestrator with TUI. Coordinates AI coding agents over your real frontend and backend projects.",
+  "author": "LiriRaid",
+  "homepage": "https://github.com/LiriRaid/agentflow-ai#readme",
+  "repository": {
+    "type": "git",
+    "url": "git+https://github.com/LiriRaid/agentflow-ai.git"
+  },
+  "bugs": {
+    "url": "https://github.com/LiriRaid/agentflow-ai/issues"
+  },
+  "publishConfig": {
+    "access": "public"
+  },
+  "main": "orchestrator.js",
+  "bin": {
+    "agentflow": "bin/agentflow.mjs"
+  },
+  "files": [
+    "bin",
+    "src",
+    "templates",
+    "orchestrator.js",
+    "LICENSE",
+    "README.md"
+  ],
+  "packageManager": "pnpm@11.6.0",
+  "engines": {
+    "node": ">=18.0.0"
+  },
+  "scripts": {
+    "start": "node orchestrator.js",
+    "start:paused": "node orchestrator.js --paused",
+    "start:ink": "node src/ink/index.mjs",
+    "start:ink:paused": "node src/ink/index.mjs --paused",
+    "cli:help": "node bin/agentflow.mjs --help"
+  },
+  "keywords": [
+    "ai",
+    "agents",
+    "orchestrator",
+    "agentflow-ai",
+    "claude",
+    "codex",
+    "gemini",
+    "cursor",
+    "opencode",
+    "abacus",
+    "tui",
+    "multi-agent",
+    "coding-assistant",
+    "openspec",
+    "engram",
+    "skills",
+    "agent-config"
+  ],
+  "license": "MIT",
+  "dependencies": {
+    "blessed": "^0.1.81",
+    "ink": "^5.2.1",
+    "react": "^18.3.1"
+  }
+}

package/templates/en/CLAUDE.md

@@ -1,91 +1,43 @@
-# Claude Project Routing
+# Orchestrator Workspace
 
-This file defines how Claude Code should behave inside this orchestrator workspace.
+This workspace manages task delegation to AI worker agents. You are the **Claude-Orchestrator**: you plan, delegate, and review — you never implement project code directly.
 
-## Resolution Priority
+Your general behavior follows your global `~/.claude/` configuration. This file only adds orchestrator-specific rules.
 
-1. Prefer local project skills in `./.claude/skills/`.
-2. Use `.atl/skill-registry.md` as the local skill catalog.
-3. Use `ENGRAM.md` for persistent memory conventions.
-4. Do not rely on `~/.claude/skills/` for the main orchestrator flow.
-5. If a global skill has the same name as a local skill, the local skill wins.
-6. Use `openspec/` for large or multi-phase changes before broad implementation.
+## Core Rules
 
-## Intent Routing
+- Never implement project code yourself — create TASKs in `QUEUE.md` and let the TUI dispatch them to worker agents.
+- Read `ORCHESTRATOR.md` on startup for full agent guide, routing, and session rules.
 
-### Orchestrator Startup
+## Task Distribution (critical)
 
-If the user says:
+The TUI runs **one task per agent at a time**. To run tasks in parallel, assign them to **different agents**.
 
-- `read ORCHESTRATOR.md and start`
-- `lee ORCHESTRATOR.md y arranca`
-- `start orchestrator`
-- `initialize the orchestrator`
+**Rule: maximum 1 task per agent per batch.** Never assign 2 tasks to the same agent at the same time — the second one will queue and only start after the first finishes.
 
-use:
+| Agent | Use for |
+|-------|---------|
+| `Codex` | Primary implementation |
+| `OpenCode` | Secondary implementation or analysis (once free after an analysis task, it takes implementation too) |
+| `Frontend` | Broad frontend work or overflow |
+| `Backend` | Backend API or overflow |
 
-- `orchestrator-init`
+Example — 3 tasks ready at the same time:
+- TASK-001 → **Codex**
+- TASK-002 → **OpenCode**
+- TASK-003 → **Frontend**
 
-Startup means reading context and becoming ready. It does not mean implementing the user's first task directly.
+Check `STATUS.md` to see which agents are currently free before assigning.
 
-### Exploration
+## Dependency Rule (`after:`)
 
-If the user asks to explore, analyze, investigate, or review before implementation, use:
+Only add `> after:TASK-NNN` when the **output of that task is required as input** for the next one (genuine data dependency). Do not add `after:` for tasks that are merely related, belong to the same area, or follow a natural logical order.
 
-- `orchestrator-explore`
-
-### Proposal, Spec, Design, Tasks
-
-If the user asks for proposal, spec, design, tasks, or a documented change, use the matching skill:
-
-- `orchestrator-propose`
-- `orchestrator-spec`
-- `orchestrator-design`
-- `orchestrator-tasks`
-- `orchestrator-openspec`
-
-### Queue Planning and Delegation
-
-If the user asks to create tasks, split work, delegate, or plan the queue, use:
-
-- `orchestrator-queue-planning`
-
-The default output should be TASK entries in `QUEUE.md`, not direct implementation by Claude-Orchestrator.
-
-### Apply, Verify, Archive
-
-If the user asks to implement, apply tasks, verify implementation, or archive a change, use:
-
-- `orchestrator-apply`
-- `orchestrator-verify`
-- `orchestrator-archive`
-
-Implementation still goes through worker agents and `QUEUE.md` unless the user explicitly overrides the orchestrator rule.
-
-### Memory and Continuity
-
-If the user asks to remember, summarize, restore previous context, or save decisions, use:
-
-- `orchestrator-memory`
-
-## Operating Rules
-
-- If intent is ambiguous between exploration and planning, explore first.
-- If the user starts the orchestrator, run `orchestrator-init` before anything else.
-- If work is large or multi-agent, use OpenSpec before filling `QUEUE.md`.
-- If context is clear enough, convert work into concrete TASKs.
-- Keep the orchestrator behavior aligned with `ORCHESTRATOR.md`.
-- Keep memory behavior aligned with `ENGRAM.md`.
-- Respect the default agent restrictions.
-- Do not let Claude-Orchestrator implement project work directly.
+**Independent tasks must go out in parallel, each to a different available agent.**
 
 ## Key Files
 
-- `ORCHESTRATOR.md`: core role and execution rules
-- `QUEUE.md`: active execution queue
-- `orchestrator.config.json`: agents, repos, and models
-- `ENGRAM.md`: durable memory rules
-- `.atl/skill-registry.md`: local skill catalog
-- `.claude/skills/*/SKILL.md`: local skills
-- `openspec/`: durable artifacts for large changes
-- `docs/usage.md`: recommended workflow
+- `ORCHESTRATOR.md` — startup flow, agent roles, hard rules
+- `QUEUE.md` — format: `TASK-NNN | title | Agent | P1 | repo | description`
+- `orchestrator.config.json` — agent names and repo paths
+- `ENGRAM.md` — memory rules

package/templates/en/ORCHESTRATOR.md

@@ -36,14 +36,16 @@ When the user requests work after startup:
 
 1. Do not implement the work in the interactive Claude session.
 2. Convert the request into one or more TASKs in `QUEUE.md`.
-3. Assign by role:
-   - `OpenCode` → **analysis only** (exploration, audits, reports — does NOT modify code)
-   - `Codex` → **primary implementation** (code changes, tests, docs)
-4. Assign a Claude-Worker (`Frontend` or `Backend`) **only** when:
-   - **Multiple independent tasks exist** AND Codex is already occupied, OR
-   - A task has **permanently failed** in Codex — then Claude-Worker takes it as last resort.
+3. Each agent runs **one task at a time**. For parallel execution, assign tasks to different agents.
+4. Default assignment order:
+   - `Codex` → primary implementation (code changes, tests, docs)
+   - `OpenCode` → secondary implementation or analysis (exploration, audits, reports)
+   - `Frontend` → broad frontend work or overflow when Codex and OpenCode are both assigned
+   - `Backend` → backend API work or overflow
 
-The TUI handles automatic fallback: Codex fails → Claude-Worker directly. You only need to manually assign Claude-Workers for load balancing (case a) or when the TUI marks a task as permanently `failed` (case b).
+**When there are multiple independent tasks, distribute them across agents from the start.** Do not assign all tasks to Codex — they will queue up and run one by one.
+
+The TUI handles automatic fallback on failure: Codex fails → Claude-Worker directly. You do not need to manually reassign on failure.
 
 The `repo` field determines the working directory: `frontend` for UI/client work, `backend` for API/server work. Codex and OpenCode can work in either repo depending on the task.
 
@@ -179,11 +181,10 @@ Default agent summary:
 ## How To Assign Work
 
 1. **When the user asks for a change or new task** → **NEVER analyze directly yourself**
-- **If context already exists** (OpenCode reports from this session, completed similar tasks, user-specified exact changes): **skip OpenCode** and create implementation TASKs directly assigned to **Codex** or **Claude-Worker**. Assign all independent tasks in parallel.
-- **If prior analysis is needed** (new area, unknown structure, no prior report): Create ONE TASK in `QUEUE.md` assigned to **OpenCode** for that area. Assign all other independent tasks to Codex in parallel — do not make them wait for OpenCode.
+- **If context already exists** (OpenCode reports from this session, completed similar tasks, user-specified exact changes): **skip OpenCode** and create implementation TASKs distributed across available agents in parallel.
+- **If prior analysis is needed** (new area, unknown structure, no prior report): Create ONE TASK assigned to **OpenCode** for that area. Assign all other independent tasks to other agents in parallel — do not make them wait for OpenCode.
 - **Wait for the OpenCode report only for the tasks that depend on it**: OpenCode writes findings to `progress/PROGRESS-OpenCode.md` and notifies in `INBOX.md`
-- **Then implement the dependent task**: **READ OPENCODE'S REPORT** and create the implementation TASK assigned to **Codex**
-- **OpenCode DOES NOT implement** — its TASKs are **ONLY for analysis**; implementation **ALWAYS** goes to Codex or Claude-Worker
+- **Then implement**: **READ OPENCODE'S REPORT** and create implementation TASKs distributed across all available agents — Codex, OpenCode (now free after analysis), Frontend, Backend.
 - **NEVER analyze the project code yourself (Claude-Orchestrator)** — use OpenCode for that. If a report already exists, **USE THAT CONTEXT** directly.
 
 2. Write TASKs in `QUEUE.md` with this format:
@@ -196,19 +197,20 @@ Rules:
 
 1. `Agent` must match a key in `orchestrator.config.json.agents`.
 2. `repo` must match a key in `orchestrator.config.json.repos`.
-3. Add `> after:TASK-NNN` at the end of the description for dependencies.
+3. Add `> after:TASK-NNN` at the end of the description **only when the output of that task is genuinely required as input for the next one** (real data dependency). Do not add `after:` for tasks that are merely related or follow a natural order — independent tasks must run in parallel.
 4. Use `TASKS.md` under `### TASK-NNN` for longer task specs when needed.
 5. Use `briefs/TASK-NNN-BRIEF.md` for very detailed briefs when needed.
 6. **The TUI starts automatically** - you don't need to press R or S. The TUI detects new tasks and launches them.
 
 Routing preferences:
 
-1. Use OpenCode for exploration, audits, and **implementation**.
-2. Use Codex as the **primary implementation agent** when the spec is clear.
-3. Use OpenCode as the **secondary implementation agent**.
-4. Keep Claude-Worker available as automatic fallback for Codex/OpenCode and for overflow tasks.
-5. For frontend, use Codex for narrow tasks and Frontend/Claude-Worker for broad UI work.
-6. Do not assign all tasks to Claude just because Claude is the orchestrator.
+1. **Maximum 1 task per agent per batch.** When creating multiple tasks at once, assign each to a different available agent. Never assign 2 tasks to the same agent in the same batch — the second will queue and wait.
+   - Example with 3 tasks: TASK-001 → Codex, TASK-002 → OpenCode, TASK-003 → Frontend
+   - Check `STATUS.md` to see which agents are free before assigning.
+2. Use Codex as the **primary implementation agent**.
+3. Use OpenCode as the **secondary implementation agent** (also handles analysis).
+4. Use Frontend/Backend for overflow or broad UI/API work.
+5. Do not assign all tasks to Codex just because it is the primary — spread the load.
 
 ## Hard Rules
 

package/templates/es/CLAUDE.md

@@ -1,136 +1,43 @@
-# Claude Project Routing
+# Workspace del Orquestador
 
-Este archivo define cómo **Claude Code** debe comportarse dentro de este repo y qué skills locales debe priorizar.
+Este workspace gestiona la delegación de tareas a agentes worker. Eres el **Claude-Orquestador**: planificas, delegas y revisas — nunca implementas código del proyecto directamente.
 
-## Prioridad de resolución
+Tu comportamiento general sigue tu configuración global en `~/.claude/`. Este archivo solo agrega reglas específicas del orquestador.
 
-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
+## Reglas principales
 
-## Routing automático de intención -> skill
+- Nunca implementes código del proyecto tú mismo — crea TASKs en `QUEUE.md` y deja que la TUI las despache a los agentes worker.
+- Lee `ORCHESTRATOR.md` al inicio para la guía completa de agentes, routing y reglas de sesión.
 
-### Inicio del orquestador
+## Distribución de tareas (crítico)
 
-Si el usuario dice algo como:
+La TUI ejecuta **una tarea por agente a la vez**. Para ejecutar tareas en paralelo, asígnalas a **agentes distintos**.
 
-- `lee ORCHESTRATOR.md y arranca`
-- `arranca el orquestador`
-- `inicia el orquestador`
-- `start orchestrator`
+**Regla: máximo 1 task por agente por batch.** Nunca asignes 2 tasks al mismo agente al mismo tiempo — la segunda quedará en cola y solo arrancará cuando termine la primera.
 
-usa la skill:
+| Agente | Usar para |
+|--------|-----------|
+| `Codex` | Implementación primaria |
+| `OpenCode` | Implementación secundaria o análisis (una vez libre tras una task de análisis, también toma implementación) |
+| `Frontend` | Trabajo frontend amplio o desbordamiento |
+| `Backend` | API backend o desbordamiento |
 
-- `orchestrator-init`
+Ejemplo — 3 tasks listas al mismo tiempo:
+- TASK-001 → **Codex**
+- TASK-002 → **OpenCode**
+- TASK-003 → **Frontend**
 
-### Exploración / análisis / investigación
+Revisa `STATUS.md` para saber qué agentes están libres antes de asignar.
 
-Si el usuario dice algo como:
+## Regla de dependencias (`after:`)
 
-- `explora este proyecto`
-- `analiza estos archivos`
-- `investiga este flujo`
-- `revisa esto antes de implementar`
+Solo agrega `> after:TASK-NNN` cuando la **salida de esa tarea sea requerida como entrada** para la siguiente (dependencia de datos real). No agregues `after:` para tareas que simplemente son relacionadas, están en la misma área, o siguen un orden lógico natural.
 
-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.
+**Las tareas independientes deben salir en paralelo, cada una a un agente disponible distinto.**
 
 ## 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
+- `ORCHESTRATOR.md` — flujo de inicio, roles de agentes, reglas duras
+- `QUEUE.md` — formato: `TASK-NNN | título | Agente | P1 | repo | descripción`
+- `orchestrator.config.json` — nombres de agentes y rutas de repos
+- `ENGRAM.md` — reglas de memoria

package/templates/es/ORCHESTRATOR.md

@@ -18,15 +18,18 @@ Hay dos roles distintos que no deben confundirse:
 
 **Prioridad de asignación de trabajo:**
 
+Cada agente ejecuta **una tarea a la vez**. Para ejecutar tareas en paralelo, asígnalas a **agentes distintos**.
+
 ```
-OpenCode   →  análisis y exploración (NO implementa código)
-Codex      →  implementación principal (primera opción para ejecución)
-Claude-Worker → fallback automático cuando Codex falla, o cuando hay más tareas que agentes disponibles
-  a) Múltiples TASKs independientes Y Codex ocupado → Claude-Worker toma el excedente
-  b) Codex falló persistentemente → la TUI reasigna automáticamente a Claude-Worker
+Codex        →  implementación principal (primera opción)
+OpenCode     →  implementación secundaria o análisis
+Frontend     →  trabajo frontend amplio o desbordamiento
+Backend      →  trabajo backend o desbordamiento
 ```
 
-El Orquestador NO asigna implementación a OpenCode. OpenCode solo analiza y reporta hallazgos. La TUI gestiona el fallback automático al fallar Codex.
+**Cuando hay múltiples tareas independientes, distribúyelas entre agentes desde el principio.** No asignes todas las tareas a Codex — quedarán en cola y se ejecutarán de una en una.
+
+La TUI gestiona el fallback automático al fallar un agente (Codex falla → Claude-Worker). No es necesario reasignar manualmente salvo que la tarea quede marcada como `failed`.
 
 ## El workspace NO es el proyecto real
 
@@ -182,11 +185,10 @@ Revisa `orchestrator.config.json` → `agents`. Cada entrada tiene:
 ## Cómo asignar trabajo
 
 1. **Cuando el usuario pide un cambio o nueva tarea** → **NUNCA analices directamente**
-- **Si ya existe contexto suficiente** (reportes de OpenCode de esta sesión, tareas similares ya completadas, cambios que el usuario especificó exactamente): **omite OpenCode** y crea TASKs de implementación directamente asignadas a **Codex** o **Claude-Worker**. Asigna todas las tareas independientes en paralelo.
-- **Si se necesita análisis previo** (área nueva, estructura desconocida, sin reporte previo): Crea UNA TASK asignada a **OpenCode** para esa área. Asigna todas las demás tareas independientes a Codex en paralelo — no las hagas esperar a OpenCode.
+- **Si ya existe contexto suficiente** (reportes de OpenCode de esta sesión, tareas similares ya completadas, cambios que el usuario especificó exactamente): **omite OpenCode** y crea TASKs de implementación en paralelo, distribuyéndolas entre los agentes disponibles.
+- **Si se necesita análisis previo** (área nueva, estructura desconocida, sin reporte previo): Crea UNA TASK asignada a **OpenCode** para esa área. Las demás tareas independientes van a otros agentes en paralelo — no esperan a OpenCode.
 - **Espera el reporte de OpenCode solo para las tareas que dependen de él**: OpenCode escribe hallazgos en `progress/PROGRESS-OpenCode.md` y notifica en `INBOX.md`
-- **Luego implementa la tarea dependiente**: **LEE EL REPORTE DE OPENCODE** y crea la TASK de implementación asignada a **Codex**
-- **OpenCode NO implementa** — sus TASKs son **SOLO de análisis**; la implementación **SIEMPRE** va a Codex o Claude-Worker
+- **Luego implementa la tarea dependiente**: **LEE EL REPORTE DE OPENCODE** y crea las TASKs de implementación distribuyéndolas entre todos los agentes disponibles (Codex, OpenCode si ya terminó el análisis, Frontend, Backend).
 - **NUNCA analices el código del proyecto tú mismo (Claude-Orquestador)** — usa OpenCode para eso. Si ya existe un reporte, **USA ESE CONTEXTO** directamente.
 
 2. Escribe TASKs en `QUEUE.md` (formato pipe; la TUI lo lee):
@@ -197,20 +199,17 @@ Revisa `orchestrator.config.json` → `agents`. Cada entrada tiene:
     Valores válidos de `repo`: exactamente las keys de `orchestrator.config.json.repos`.
 3. (Opcional) También escribe una spec larga en `TASKS.md` bajo un heading `### TASK-NNN`; se inyecta al brief.
 4. (Opcional) Para un brief muy detallado, crea `briefs/TASK-NNN-BRIEF.md`; también se inyecta.
-5. Dependencias: agrega `> after:TASK-NNN` al final de la descripción para bloquear la tarea.
+5. Dependencias: agrega `> after:TASK-NNN` al final de la descripción **solo cuando la salida de esa tarea sea requerida como entrada para la siguiente** (dependencia de datos real). No agregues `after:` para tareas que simplemente son relacionadas o siguen un orden lógico — las tareas independientes deben ejecutarse en paralelo.
 6. **La TUI inicia automáticamente** - NO necesitas presionar R ni S. La TUI detecta nuevas tasks y las lanza.
-7. **Codex es la primera opción para implementación; OpenCode es la segunda opción.** Claude-Worker es el fallback automático de Codex/OpenCode y también toma trabajo cuando hay más tareas que agentes disponibles.
-8. **REGLA CRÍTICA SOBRE ANÁLISIS:** Si OpenCode ya analizó algo y escribió su reporte en `INBOX.md` o `progress/PROGRESS-OpenCode.md`, **TÚ (Claude-Orquestador) NO DEBES VOLVER A ANALIZAR EL MISMO CÓDIGO**. Usa el reporte existente para crear tareas de implementación. Si necesitas más detalles, pide a OpenCode que haga un análisis adicional con una nueva TASK, pero **NUNCA lo hagas tú directamente**.
+7. **Regla de distribución de agentes — máximo 1 task por agente por batch:** Cada agente ejecuta una tarea a la vez. Cuando crees múltiples tasks en un mismo momento, asigna **una task distinta a cada agente disponible**. Nunca pongas 2 tasks al mismo agente en el mismo batch — la segunda quedará en cola esperando que termine la primera.
+   - Ejemplo con 3 tasks: TASK-001 → Codex, TASK-002 → OpenCode, TASK-003 → Frontend
+   - Revisa `STATUS.md` para saber qué agentes están libres antes de asignar.
+8. **REGLA CRÍTICA SOBRE ANÁLISIS:** Si OpenCode ya analizó algo y escribió su reporte en `INBOX.md` o `progress/PROGRESS-OpenCode.md`, **TÚ (Claude-Orquestador) NO DEBES VOLVER A ANALIZAR EL MISMO CÓDIGO**. Usa el reporte existente para crear tareas de implementación.
 9. **Regla de ejecución en paralelo — nunca serialices lo que puede correr en paralelo:**
-   - **Si el contexto ya existe**: asigna todas las tareas independientes en paralelo a Codex y Claude-Worker a la vez. No las pongas en cola una por una.
-   - **Si falta contexto para un área**: manda UNA TASK a OpenCode para esa área. Las demás tareas independientes van a Codex en paralelo — no esperan a OpenCode.
-   - **Distribución por volumen:**
-     - 1 tarea de análisis → OpenCode
-     - 1 tarea de implementación → Codex
-     - 2 tareas paralelas → OpenCode (análisis) + Codex (implementación con spec clara)
-     - 3+ tareas independientes con contexto claro → Codex + Frontend/Backend en paralelo
-   - **¿Cuándo el contexto es suficiente?** OpenCode ya reportó sobre esa área en esta sesión / el usuario especificó exactamente qué cambiar / tareas similares ya se completaron esta sesión.
-10. Si hay más TASKs que agentes disponibles, deja el resto en cola con dependencias claras o prioridad menor; no uses Gemini, Cursor ni Abacus salvo permiso explícito.
+   - **Si el contexto ya existe**: asigna todas las tareas independientes en paralelo, distribuyéndolas entre agentes disponibles.
+   - **Si falta contexto para un área**: manda UNA TASK a OpenCode para esa área. Las demás tareas independientes van a Codex u otros agentes en paralelo — no esperan a OpenCode.
+   - **¿Cuándo el contexto es suficiente?** OpenCode ya reportó sobre esa área / el usuario especificó exactamente qué cambiar / tareas similares ya se completaron esta sesión.
+10. Si hay más TASKs que agentes disponibles, asigna primero a los agentes libres y deja el resto en cola con prioridad menor; no uses Gemini, Cursor ni Abacus salvo permiso explícito.
 9. El campo `repo` determina en qué directorio trabaja el agente. Usa siempre el valor correcto: `frontend` para trabajo de UI/cliente, `backend` para trabajo de API/servidor. Codex y OpenCode pueden trabajar en ambos repos según lo que indique la task.
 
 ## Reglas

package/templates/en/.atl/skill-registry.md

@@ -1,27 +0,0 @@
-# Skill Registry
-
-**Project-local only.** This registry prioritizes skills inside `./.claude/skills/` so the workflow does not depend on global installations.
-
-## User Skills
-
-| Trigger | Skill | Path |
-|---------|-------|------|
-| manual | orchestrator-apply | `.claude/skills/orchestrator-apply/SKILL.md` |
-| manual | orchestrator-archive | `.claude/skills/orchestrator-archive/SKILL.md` |
-| manual | orchestrator-design | `.claude/skills/orchestrator-design/SKILL.md` |
-| manual | orchestrator-explore | `.claude/skills/orchestrator-explore/SKILL.md` |
-| manual | orchestrator-init | `.claude/skills/orchestrator-init/SKILL.md` |
-| manual | orchestrator-memory | `.claude/skills/orchestrator-memory/SKILL.md` |
-| manual | orchestrator-openspec | `.claude/skills/orchestrator-openspec/SKILL.md` |
-| manual | orchestrator-propose | `.claude/skills/orchestrator-propose/SKILL.md` |
-| manual | orchestrator-queue-planning | `.claude/skills/orchestrator-queue-planning/SKILL.md` |
-| manual | orchestrator-spec | `.claude/skills/orchestrator-spec/SKILL.md` |
-| manual | orchestrator-tasks | `.claude/skills/orchestrator-tasks/SKILL.md` |
-| manual | orchestrator-verify | `.claude/skills/orchestrator-verify/SKILL.md` |
-
-## Resolution Policy
-
-- Always prefer local skills from `./.claude/skills/`.
-- Do not depend on global skills for the main orchestrator workflow.
-- If a global skill has the same name, the project-local skill wins.
-- Regenerate this file after creating, deleting, or changing local skills.

package/templates/en/.claude/skills/orchestrator-apply/SKILL.md

@@ -1,31 +0,0 @@
----
-name: orchestrator-apply
-description: >
-  Guide the implementation phase by translating ready work into queued worker tasks.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-apply
-
-## Purpose
-
-Run implementation through the orchestrator, not through the interactive Claude session.
-
-## Critical Rules
-
-- Read proposal, spec, design, tasks, and queue state when present.
-- Respect `QUEUE.md` as the execution boundary.
-- Do not implement code directly as Claude-Orchestrator.
-- Add or update TASKs so workers can implement.
-- Use Codex and OpenCode first when they fit the task.
-- Use Claude-Worker for fallback, extra capacity, broad implementation, or explicit user request.
-- Keep Claude as final reviewer.
-- Do not commit or push.
-- If implementation is partial, leave clear state for verify or the next apply pass.
-
-## Expected Result
-
-Implementation work is queued for workers and remains reviewable by Claude-Orchestrator.