@liriraid/agentflow-ai 1.0.27 → 1.0.29

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.

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

@@ -1,26 +0,0 @@
----
-name: orchestrator-archive
-description: >
-  Close and archive a completed OpenSpec change after implementation and verification.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-archive
-
-## Purpose
-
-Close a change with a durable summary of what was done and what remains.
-
-## Critical Rules
-
-- Confirm proposal, spec, design, tasks, and verify report are coherent.
-- Write or update `archive-report.md`.
-- Note completed work, remaining risks, and follow-ups.
-- Do not archive incomplete work as complete.
-
-## Expected Result
-
-A closed change with a useful archive report.

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

@@ -1,27 +0,0 @@
----
-name: orchestrator-design
-description: >
-  Create or update the technical design for a change.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-design
-
-## Purpose
-
-Document the technical approach, tradeoffs, affected files, risks, and rollout plan.
-
-## Critical Rules
-
-- Use `openspec/changes/<change-name>/design.md`.
-- Prefer existing project patterns.
-- Capture tradeoffs and risks clearly.
-- Keep design aligned with the proposal and spec.
-- Do not implement code directly.
-
-## Expected Result
-
-A technical design that can be broken into executable tasks.

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

@@ -1,32 +0,0 @@
----
-name: orchestrator-explore
-description: >
-  Explore, analyze, or investigate the project before proposing or delegating implementation.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.1"
----
-
-# Skill: orchestrator-explore
-
-## Purpose
-
-Gather useful context before creating TASKs or OpenSpec artifacts.
-
-## Critical Rules
-
-- Understand the user's exact scope first — clarify by asking the user directly, **NOT by reading project files yourself**.
-- Prefer exploration before implementation when context is unclear.
-- Use **ONLY OpenCode** as the exploration agent when deep codebase analysis is needed — its role is **EXCLUSIVELY analysis**, **NEVER implementation**.
-- When delegating exploration to OpenCode, include in the brief exactly what it must report: flows, dependencies, architecture findings, inconsistencies, etc.
-- Do not fill `QUEUE.md` with implementation tasks until enough context exists.
-- Summarize findings in actionable terms: what exists, what is missing, what risks exist, and what tasks follow.
-- If the change is large or multi-phase, move toward OpenSpec.
-- If work is clear, convert findings into concrete TASKs using `orchestrator-queue-planning`.
-- **STRICT RULE: When OpenCode delivers its report in INBOX.md, use THOSE findings to create implementation TASKs (assigned to Codex or Claude-Worker). Under NO circumstances should Claude-Orchestrator re-analyze the code itself if OpenCode has already done so. Read the report in `progress/PROGRESS-OpenCode.md` or INBOX.md and base your decisions on that analysis.**
-- If OpenCode's report is insufficient, ask OpenCode to deepen analysis on a specific area with a new analysis TASK, but **DO NOT do it yourself**.
-
-## Expected Result
-
-The orchestrator can decide whether to plan TASKs or continue investigation. **The final result MUST be one or more TASKs in QUEUE.md assigned to Codex or Claude-Worker for implementation, NOT more analysis by Claude-Orchestrator.**

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

@@ -1,32 +0,0 @@
----
-name: orchestrator-init
-description: >
-  Initialize the orchestrator session: read ORCHESTRATOR.md, config, queue, progress, handoffs, and visible state before asking for the next priority.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-init
-
-Trigger examples: "start", "start orchestrator", "read ORCHESTRATOR.md and start", "lee ORCHESTRATOR.md y arranca".
-
-## Purpose
-
-Prepare a new orchestrator session without executing project work directly.
-
-## Critical Rules
-
-- Read `ORCHESTRATOR.md` completely before responding.
-- Read `orchestrator.config.json` to understand repos, agents, and models.
-- Read `QUEUE.md` to detect pending, active, and completed work.
-- Read the newest handoff if present.
-- Read progress files if present.
-- Use `PROJECT.md` and `openspec/` as context when available.
-- Do not implement code during startup.
-- Reply that the orchestrator is ready and ask what the user wants to prioritize.
-
-## Expected Result
-
-Claude is ready as Claude-Orchestrator and has not performed project implementation directly.

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

@@ -1,26 +0,0 @@
----
-name: orchestrator-memory
-description: >
-  Use persistent memory for decisions, discoveries, bugs, setup notes, and session summaries.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-memory
-
-## Purpose
-
-Preserve durable context for future sessions.
-
-## Critical Rules
-
-- Follow `ENGRAM.md`.
-- Save decisions, bug fixes, discoveries, setup changes, and session summaries.
-- Do not save secrets, credentials, API keys, or private customer data.
-- Memory complements `QUEUE.md`, OpenSpec, and handoffs. It does not replace them.
-
-## Expected Result
-
-Future sessions can resume with useful context instead of rediscovering everything.

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

@@ -1,35 +0,0 @@
----
-name: orchestrator-openspec
-description: >
-  Create or update OpenSpec artifacts for large or multi-phase changes.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-openspec
-
-## Purpose
-
-Use `openspec/` as the durable planning layer before delegating larger implementation work.
-
-## When To Use
-
-- Multi-phase changes
-- Multi-agent changes
-- User explicitly asks for proposal, spec, design, or tasks
-- The change needs durable traceability
-
-## Critical Rules
-
-- Create changes under `openspec/changes/<change-name>/`.
-- Use clear kebab-case change names.
-- Keep proposal, spec, design, tasks, verify report, and archive report consistent.
-- `tasks.md` should be translatable into `QUEUE.md`.
-- Do not queue large implementation work before the OpenSpec artifacts are clear.
-- Do not force OpenSpec for tiny direct changes.
-
-## Expected Result
-
-A coherent OpenSpec change that can feed the live queue.

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

@@ -1,26 +0,0 @@
----
-name: orchestrator-propose
-description: >
-  Create or update the proposal for a significant change before implementation.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-propose
-
-## Purpose
-
-Define what the change is, why it matters, what is in scope, and what is explicitly out of scope.
-
-## Critical Rules
-
-- Read the user's request and current project context.
-- Use `openspec/changes/<change-name>/proposal.md`.
-- Keep the proposal short, actionable, and durable.
-- Do not implement code while writing the proposal.
-
-## Expected Result
-
-A proposal that can move into spec, design, tasks, and queue planning.

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

@@ -1,50 +0,0 @@
----
-name: orchestrator-queue-planning
-description: >
-  Convert user requests, specs, or findings into concrete TASK entries for QUEUE.md.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.1"
----
-
-# Skill: orchestrator-queue-planning
-
-## Purpose
-
-Turn the user's request into executable queue work for the TUI.
-
-## Agent Assignment Rules
-
-### OpenCode — analysis only
-- Use for exploration, audits, context reading, and structured reports.
-- **Do not assign implementation** — OpenCode does not modify project files.
-- If work needs prior analysis, create an OpenCode TASK first, then a Codex TASK with `> after:TASK-NNN`.
-
-### Codex — primary implementation
-- Use for implementation, code changes, tests, and docs when the spec is clear.
-- It is the primary execution agent.
-- If Codex fails persistently, the TUI automatically reassigns to Claude-Worker (Frontend/Backend).
-
-### Claude-Worker (Frontend / Backend)
-- Automatic fallback when Codex fails.
-- Also takes overflow work when both Codex and OpenCode are busy and more tasks are pending.
-- Frontend-only projects: always use `Frontend`; backend work: use `Backend`.
-
-## Critical Rules
-
-- Create small, concrete, executable TASKs.
-- Every TASK must include agent, priority, repo, and a clear description.
-- Use `> after:TASK-NNN` for dependencies.
-- Do not implement the task directly as Claude-Orchestrator.
-- Distribution by task count:
-  - **1 analysis task**: OpenCode
-  - **1 implementation task**: Codex
-  - **2 parallel tasks**: OpenCode (analysis) + Codex (implementation when spec is clear)
-  - **3+ tasks** with Codex busy: overflow goes to `Frontend` (FE repo) or `Backend` (BE repo)
-- Keep `QUEUE.md` aligned with the user's current objective.
-- **Never assign implementation to OpenCode.**
-
-## Expected Result
-
-`QUEUE.md` contains clear TASKs ready for the TUI to run.

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

@@ -1,27 +0,0 @@
----
-name: orchestrator-spec
-description: >
-  Create or update the behavioral specification for a change.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-spec
-
-## Purpose
-
-Turn the proposal into clear required behavior and acceptance criteria.
-
-## Critical Rules
-
-- Use `openspec/changes/<change-name>/specs/spec.md`.
-- Focus on observable behavior.
-- Include acceptance criteria when useful.
-- Do not mix implementation details into the spec unless needed for clarity.
-- Do not implement code directly.
-
-## Expected Result
-
-A spec that can guide design, tasks, implementation, and verification.

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

@@ -1,27 +0,0 @@
----
-name: orchestrator-tasks
-description: >
-  Break a change into implementation tasks that can later be translated into QUEUE.md.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-tasks
-
-## Purpose
-
-Convert proposal, spec, and design into concrete implementation tasks.
-
-## Critical Rules
-
-- Use `openspec/changes/<change-name>/tasks.md`.
-- Tasks should be small, ordered, and delegable.
-- Mark dependencies clearly.
-- Mark which tasks are ready to become `QUEUE.md` entries.
-- Do not implement tasks directly.
-
-## Expected Result
-
-A task list ready for queue planning.

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

@@ -1,27 +0,0 @@
----
-name: orchestrator-verify
-description: >
-  Verify that implementation matches proposal, spec, design, tasks, and user intent.
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-verify
-
-## Purpose
-
-Let Claude-Orchestrator review worker output before accepting it.
-
-## Critical Rules
-
-- Read proposal, spec, design, tasks, queue entries, logs, and reports when present.
-- Compare implementation against the requested behavior.
-- Identify gaps, regressions, missing tests, or unclear results.
-- Do not accept worker output blindly.
-- Create follow-up TASKs in `QUEUE.md` if verification finds work to do.
-
-## Expected Result
-
-A clear verification decision and any required follow-up tasks.

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

@@ -1,133 +0,0 @@
-# Skill Registry
-
-**Project-local only.** This registry prioritizes skills inside `./.claude/skills/` so the workflow does not depend on global installations such as `gentle-ai`.
-
-## 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` |
-
-## Compact Rules
-
-### orchestrator-apply
-- 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.
-
-### orchestrator-archive
-- Confirm proposal, spec, design, tasks, and verify report are coherent.
-- Write or update `archive-report.md`.
-- Note completed work, remaining risks, and follow-ups.
-- Do not archive incomplete work as complete.
-
-### orchestrator-design
-- Use `openspec/changes/<change-name>/design.md`.
-- Prefer existing project patterns.
-- Capture tradeoffs and risks clearly.
-- Keep design aligned with the proposal and spec.
-- Do not implement code directly.
-
-### orchestrator-explore
-- Understand the user's exact scope first.
-- Prefer exploration before implementation when context is unclear.
-- Use OpenCode as the first support worker for broad reading, audits, and structured findings when appropriate.
-- Do not fill `QUEUE.md` with implementation tasks until enough context exists.
-- Summarize findings in actionable terms: what exists, what is missing, what risks exist, and what tasks follow.
-- If the change is large or multi-phase, move toward OpenSpec.
-- If work is clear, convert findings into concrete TASKs.
-
-### orchestrator-init
-- Read `ORCHESTRATOR.md` completely before responding.
-- Read `orchestrator.config.json` to understand repos, agents, and models.
-- Read `QUEUE.md` to detect pending, active, and completed work.
-- Read the newest handoff if present.
-- Read progress files if present.
-- Use `PROJECT.md` and `openspec/` as context when available.
-- Do not implement code during startup.
-- Reply that the orchestrator is ready and ask what the user wants to prioritize.
-
-### orchestrator-memory
-- Follow `ENGRAM.md`.
-- Save decisions, bug fixes, discoveries, setup changes, and session summaries.
-- Do not save secrets, credentials, API keys, or private customer data.
-- Memory complements `QUEUE.md`, OpenSpec, and handoffs. It does not replace them.
-
-### orchestrator-openspec
-- Multi-phase changes
-- Multi-agent changes
-- User explicitly asks for proposal, spec, design, or tasks
-- The change needs durable traceability
-- Create changes under `openspec/changes/<change-name>/`.
-- Use clear kebab-case change names.
-- Keep proposal, spec, design, tasks, verify report, and archive report consistent.
-- `tasks.md` should be translatable into `QUEUE.md`.
-
-### orchestrator-propose
-- Read the user's request and current project context.
-- Use `openspec/changes/<change-name>/proposal.md`.
-- Keep the proposal short, actionable, and durable.
-- Do not implement code while writing the proposal.
-
-### orchestrator-queue-planning
-- Create small, concrete, executable TASKs.
-- Every TASK must include agent, priority, repo, and a clear description.
-- Use `> after:TASK-NNN` for dependencies.
-- Do not implement the task directly as Claude-Orchestrator.
-- Prefer assigning first executable work to `Codex` or `OpenCode` when they are suitable.
-- Use Claude-Worker only for fallback, extra capacity, sensitive work, broad implementation, or when explicitly requested.
-- Codex can work in `repo=frontend`, but only for narrow, clear, verifiable tasks.
-- Broad frontend work should go to `Frontend`/Claude-Worker.
-
-### orchestrator-spec
-- Use `openspec/changes/<change-name>/specs/spec.md`.
-- Focus on observable behavior.
-- Include acceptance criteria when useful.
-- Do not mix implementation details into the spec unless needed for clarity.
-- Do not implement code directly.
-
-### orchestrator-tasks
-- Use `openspec/changes/<change-name>/tasks.md`.
-- Tasks should be small, ordered, and delegable.
-- Mark dependencies clearly.
-- Mark which tasks are ready to become `QUEUE.md` entries.
-- Do not implement tasks directly.
-
-### orchestrator-verify
-- Read proposal, spec, design, tasks, queue entries, logs, and reports when present.
-- Compare implementation against the requested behavior.
-- Identify gaps, regressions, missing tests, or unclear results.
-- Do not accept worker output blindly.
-- Create follow-up TASKs in `QUEUE.md` if verification finds work to do.
-
-## Project Conventions
-
-| File | Path | Notes |
-|------|------|-------|
-| CLAUDE.md | `CLAUDE.md` |  |
-| ORCHESTRATOR.md | `ORCHESTRATOR.md` | Orchestrator session entry point |
-| PROJECT.md | `PROJECT.md` |  |
-| README.md | `README.md` |  |
-
-## Resolution Policy
-
-- Always prefer local skills from `./.claude/skills/`.
-- Do not depend on `~/.claude/skills/` for the main orchestrator workflow.
-- If a global skill has the same name as a project-local skill, the local skill wins.
-- Regenerate this file after creating, deleting, or changing local skills.

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

@@ -1,32 +0,0 @@
----
-name: orchestrator-apply
-description: >
-  Guía la fase de implementación de un cambio siguiendo proposal, spec, design y tasks.
-  Trigger: "implementa", "aplica el cambio", "ejecuta las tareas", "ponlo en marcha"
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-apply
-
-## Propósito
-
-Ejecutar implementación de forma controlada y alineada al cambio documentado, sin dejar que una sola IA improvise todo sin control.
-
-## Reglas críticas
-
-- Lee proposal, spec, design y tasks antes de implementar.
-- Respeta `QUEUE.md` y el reparto de trabajo del orquestador.
-- Usa agentes de apoyo para ejecutar, pero mantén a Claude como árbitro principal de revisión.
-- Si hay tareas independientes suficientes, no esperes pasivamente a que Codex u OpenCode terminen: asigna también una TASK a un Claude-Worker (`Backend` o `Frontend`) para que Claude avance trabajo de código en paralelo.
-- OpenCode puede implementar código además de explorar y auditar cuando la TASK esté claramente definida.
-- Los cambios no deben darse por aceptados automáticamente; Claude debe revisarlos antes de darlos por buenos si la tarea lo requiere.
-- No hagas commit ni push.
-- Si la implementación queda parcial, deja el estado claro para verify o una siguiente tanda de apply.
-- Si el cambio se desvía del plan, documenta la desviación antes de seguir.
-
-## Resultado esperado
-
-Implementación alineada al cambio, con estado claro para la siguiente fase.

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

@@ -1,28 +0,0 @@
----
-name: orchestrator-archive
-description: >
-  Cierra y archiva un cambio cuando ya fue implementado y verificado.
-  Trigger: "archiva el cambio", "cierra el change", "finaliza el cambio", "mueve al archive"
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-archive
-
-## Propósito
-
-Cerrar formalmente un cambio para que el orquestador mantenga un historial limpio y reusable.
-
-## Reglas críticas
-
-- Confirma que proposal, spec, design, tasks y verify-report estén en estado razonable.
-- Crea o actualiza `archive-report.md`.
-- Mueve el change al área de archivo cuando corresponda.
-- Si el cambio deja aprendizajes importantes, sugiere guardarlos también en Engram.
-- No hagas commit ni push como parte del archive.
-
-## Resultado esperado
-
-Un cambio cerrado correctamente y listo para futuras referencias.

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

@@ -1,32 +0,0 @@
----
-name: orchestrator-design
-description: >
-  Crea o actualiza el diseño técnico del cambio con decisiones de arquitectura y enfoque de implementación.
-  Trigger: "haz design", "diseño técnico", "arquitectura del cambio", "enfoque técnico"
-license: MIT
-metadata:
-  owner: agentflow
-  version: "1.0"
----
-
-# Skill: orchestrator-design
-
-## Propósito
-
-Definir cómo debería implementarse el cambio dentro del sistema real, respetando el flujo del orquestador y del proyecto objetivo.
-
-## Reglas críticas
-
-- Lee propuesta y spec antes de escribir diseño.
-- Crea o actualiza `openspec/changes/<change-name>/design.md`.
-- Documenta:
-  - capas afectadas
-  - archivos probables
-  - riesgos técnicos
-  - decisiones de arquitectura
-  - tradeoffs
-- Si una decisión es importante y reusable, recomienda guardarla también en Engram.
-
-## Resultado esperado
-
-Un diseño técnico accionable que permita dividir tareas sin perder consistencia.

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

@@ -1,34 +0,0 @@
----
-name: orchestrator-explore
-description: >
-  Explora, analiza o investiga el proyecto antes de proponer cambios. Ideal cuando el usuario pide entender archivos, flujos o arquitectura antes de delegar implementación.
-  Trigger: "explora", "analiza", "investiga", "revisa este proyecto", "revisa estos archivos"
-license: MIT
-metadata:
-  owner: agentflow
-  version: "0.2"
----
-
-# Skill: orchestrator-explore
-
-## Propósito
-
-Guiar la fase de exploración del orquestador para reunir contexto útil antes de crear o delegar tareas.
-
-## Reglas críticas
-
-- Empieza por entender el alcance exacto del pedido del usuario — acláralo preguntándole directamente, **NO leyendo archivos del proyecto tú mismo**.
-- Si hace falta lectura amplia, prioriza exploración y análisis antes de planear implementación.
-- Usa **SOLO OpenCode** como agente de exploración cuando necesites análisis profundo del codebase — su rol es **EXCLUSIVAMENTE análisis**, **NUNCA implementación**.
-- Al delegar exploración a OpenCode, incluye en el brief exactamente qué debe reportar: flujos, dependencias, hallazgos de arquitectura, inconsistencias, etc.
-- No llenes `QUEUE.md` con implementación hasta tener suficiente contexto.
-- Resume hallazgos en términos accionables: qué existe, qué falta, qué riesgo hay y qué tareas salen de eso.
-- Si la exploración revela un cambio grande o multifase, el siguiente paso natural es abrir o actualizar un change en `openspec/`.
-- Si descubres una línea clara de trabajo, el siguiente paso natural es convertir hallazgos en TASKs concretas con `orchestrator-queue-planning`.
-- Mantén el foco dentro del alcance pedido; explorar no es rediseñar todo el sistema.
-- **REGLA ESTRICTA: Cuando OpenCode entregue su reporte en INBOX.md, usa ESOS hallazgos para crear las TASKs de implementación (asignadas a Codex o Claude-Worker). NUNCA, bajo ninguna circunstancia, vuelvas a analizar el código tú mismo (Claude-Orquestador) si OpenCode ya lo hizo. Lee el reporte en `progress/PROGRESS-OpenCode.md` o el INBOX.md y basa tus decisiones en ese análisis.**
-- Si el reporte de OpenCode es insuficiente, pide a OpenCode que profundice en un área específica con una nueva TASK de análisis, pero NO lo hagas tú directamente.
-
-## Resultado esperado
-
-Una exploración útil que permita al orquestador decidir si ya puede crear TASKs o si necesita una investigación adicional. **El resultado final DEBE ser una o más TASKs en QUEUE.md asignadas a Codex o Claude-Worker para implementación, NO más análisis por parte de Claude-Orquestador.**