@liriraid/agentflow-ai 1.0.10

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

@@ -0,0 +1,31 @@
+---
+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.0"
+---
+
+# Skill: orchestrator-queue-planning
+
+## Purpose
+
+Turn the user's request into executable queue work for the TUI.
+
+## 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.
+- 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.
+- Keep `QUEUE.md` aligned with the user's current objective.
+
+## Expected Result
+
+`QUEUE.md` contains clear TASKs ready for the TUI to run.

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

@@ -0,0 +1,27 @@
+---
+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

@@ -0,0 +1,27 @@
+---
+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

@@ -0,0 +1,27 @@
+---
+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/en/.codex/README.md

@@ -0,0 +1,7 @@
+# Codex Local Config
+
+This folder reserves project-local configuration for Codex.
+
+- Use it as the reusable local base for Codex.
+- It can later hold prompts, profiles, rules, or plugins.
+- The workflow should not depend only on global user config.

package/templates/en/.opencode/README.md

@@ -0,0 +1,7 @@
+# OpenCode Local Config
+
+This folder reserves project-local configuration for OpenCode.
+
+- Use it as the reusable local base for OpenCode.
+- It can later hold prompts, rules, profiles, or conventions.
+- The workflow should not depend only on global user config.

package/templates/en/AGENT-CONFIG.md

@@ -0,0 +1,75 @@
+# Agent Config
+
+This file documents the reusable agent configuration layer.
+
+## Goal
+
+Separate two levels:
+
+1. **Runtime config**
+   - Lives in `orchestrator.config.json` under `agents` and `repos`.
+   - Controls which agents the engine can launch and which repos they work on.
+
+2. **Agent profile config**
+   - Lives in `orchestrator.config.json` under `agentProfiles`.
+   - Describes local config folders and shared settings for each CLI family.
+
+This allows the workspace to run one agent, the default three-agent setup, or a larger future setup without redesigning the config.
+
+## Design Rule
+
+- `agents`: operational worker instances visible to the TUI.
+- `agentProfiles`: reusable configuration by agent family.
+
+Examples:
+
+- `Backend` and `Frontend` share the `claude` profile.
+- `Codex` uses the `codex` profile.
+- `OpenCode` uses the `opencode` profile.
+
+## Claude-Orchestrator vs Claude-Worker
+
+The `claude` profile can appear in two operational roles:
+
+- **Claude-Orchestrator**: the interactive session that reads `ORCHESTRATOR.md`, updates `QUEUE.md`, delegates, monitors, and reviews.
+- **Claude-Worker**: workers such as `Backend` and `Frontend`, launched by the TUI, that can edit code when they receive a TASK.
+
+Claude-Orchestrator must not modify the real project directly. If Claude should work on code, assign a TASK to `Backend` or `Frontend`.
+
+Default routing should put executable work on Codex or OpenCode first when they are suitable. Claude-Worker is used for fallback, extra capacity, sensitive work, or broad frontend/backend implementation.
+
+## Suggested `agentProfiles` Fields
+
+| Field | Required | Purpose |
+| --- | --- | --- |
+| `enabled` | No | Whether the profile is active for the project |
+| `localConfigDir` | No | Local project folder for that agent |
+| `skillsDir` | No | Local skills folder, when applicable |
+| `primary` | No | Whether this profile is the main orchestrator profile |
+| `useForOrchestration` | No | Whether this profile can orchestrate |
+| `notes` | No | Operational notes or restrictions |
+
+## Initial Convention
+
+- `claude` is the primary profile.
+- `codex` and `opencode` are support profiles.
+- Other profiles can exist while remaining disabled by default.
+
+## Suggested Local Folders
+
+- `.claude/`
+- `.codex/`
+- `.opencode/`
+
+These folders are project-local. They should not depend only on the user's global home configuration.
+
+## Priority
+
+If both global and local agent configuration exist, the local project config should win for this orchestrator workflow.
+
+## Relationship With Skills
+
+- Claude uses `.claude/skills/` as the main project skill base.
+- Codex and OpenCode can have their own local config even if they do not use the same skill model today.
+- OpenCode can explore, audit, and implement when the TASK is clear.
+- The design should allow richer local layers for additional agents later.

package/templates/en/CLAUDE.md

@@ -0,0 +1,91 @@
+# Claude Project Routing
+
+This file defines how Claude Code should behave inside this orchestrator workspace.
+
+## Resolution Priority
+
+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.
+
+## Intent Routing
+
+### Orchestrator Startup
+
+If the user says:
+
+- `read ORCHESTRATOR.md and start`
+- `lee ORCHESTRATOR.md y arranca`
+- `start orchestrator`
+- `initialize the orchestrator`
+
+use:
+
+- `orchestrator-init`
+
+Startup means reading context and becoming ready. It does not mean implementing the user's first task directly.
+
+### Exploration
+
+If the user asks to explore, analyze, investigate, or review before implementation, use:
+
+- `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.
+
+## 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

package/templates/en/ENGRAM.md

@@ -0,0 +1,50 @@
+# Engram Memory
+
+This file defines how the orchestrator workspace should use persistent memory.
+
+## Purpose
+
+Engram keeps project continuity outside the short chat context. Use it to preserve decisions, discoveries, bugs, handoffs, and session summaries.
+
+## When To Save Memory
+
+Save memory after:
+
+- architectural decisions
+- routing or agent-policy changes
+- bug fixes
+- important discoveries
+- setup or configuration changes
+- completed sessions with useful context
+- non-obvious tradeoffs
+
+## Recommended Format
+
+Use concise structured notes:
+
+```text
+**What**: What changed or was discovered
+**Why**: Why it matters
+**Where**: Files or areas affected
+**Learned**: Gotchas or durable lessons
+```
+
+## Relationship With The Orchestrator
+
+Engram complements:
+
+- `ORCHESTRATOR.md`
+- `CLAUDE.md`
+- `QUEUE.md`
+- `openspec/`
+- handoff files
+
+It does not replace the queue or the TUI. Runtime work still goes through `QUEUE.md`.
+
+## Rules
+
+- Save memory only for information that will matter in a future session.
+- Do not store secrets, API keys, credentials, or private customer data.
+- Prefer short, searchable titles.
+- Use project-level memory for this repo's architecture and workflow.
+- At the end of meaningful work, save a session summary.

package/templates/en/ORCHESTRATOR.md

@@ -0,0 +1,192 @@
+# Orchestrator Session Start
+
+> This file is the entry point for every orchestrator session.
+> Start prompt: `Read <absolute-path-to-this-file> and start`.
+
+---
+
+## Your Role
+
+You are the **Orchestrator** for this multi-agent workspace. Your interactive Claude session must not implement project work directly. Your job is to read context, split work, write executable TASKs into `QUEUE.md`, monitor results, and review outcomes.
+
+The TUI (`orchestrator.js`) reads `QUEUE.md` and launches the real worker agents.
+
+## Claude Roles
+
+There are two different Claude roles:
+
+1. **Claude-Orchestrator**: the interactive session that reads this file, plans, updates `QUEUE.md`, reviews logs, and decides next steps. This role does not edit the real project directly.
+2. **Claude-Worker**: workers launched by the TUI through the `claude` CLI, such as `Backend` and `Frontend`. These workers can edit code only when a TASK explicitly assigns work to them.
+
+Do not confuse these roles. If the user asks for implementation, Claude-Orchestrator should create or update TASKs in `QUEUE.md` instead of implementing the request itself.
+
+## Default Execution Policy
+
+By default, use only these agent families:
+
+- **Codex**
+- **OpenCode**
+- **Claude-Worker** only as fallback or extra capacity
+
+Do not assign tasks to Gemini, Cursor, or Abacus unless the user explicitly enables them for the current session.
+
+### First-Routing Rule
+
+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. Prefer assigning the first executable work to `Codex` or `OpenCode`.
+4. Assign a Claude-Worker only when:
+   - Codex and/or OpenCode already have useful work in flight,
+   - a task is blocked by Codex/OpenCode quota, rate limit, token limits, or repeated failure,
+   - the task is highly sensitive and needs Claude as the worker,
+   - the user explicitly asks Claude to take the worker task.
+
+For frontend work, prefer `Codex` for narrow, well-scoped tasks and `OpenCode` for exploration/audits. Use `Frontend`/Claude-Worker for broader UI implementation, fallback, or when the other allowed agents are already occupied.
+
+## Startup Checklist
+
+When the user says something like `Read ORCHESTRATOR.md and start`, do this:
+
+1. Read this file completely.
+2. Read `<projectName>-plan.md`, `PLAN.md`, or `plan.md` if present.
+3. Read the newest `handoffs/HANDOFF-*.md` if the folder exists.
+4. Read `QUEUE.md` to understand pending, active, and completed work.
+5. Read `orchestrator.config.json` to know available agents and repos.
+6. Read all `progress/PROGRESS-*.md` files if present.
+7. Read `ENGRAM.md` and follow the memory rules.
+8. Use `openspec/` for large or multi-phase changes.
+9. Tell the user the orchestrator is ready and ask what to prioritize.
+
+Startup is context loading only. Do not create project code changes during startup.
+
+## Away Mode
+
+If the user says something like:
+
+- `I will be away for 2 hours`
+- `monitor while I am gone`
+- `keep checking`
+- `continue while I am away`
+
+enter **Away Mode** for that session.
+
+In Away Mode:
+
+1. Check work state every 5 minutes.
+2. Read `QUEUE.md`, completed tasks, active tasks, idle agents, progress files, and blocked tasks.
+3. Assign new useful TASKs when agents become idle, as long as the work stays within the user's stated goal.
+4. Update `QUEUE.md` and `TASKS.md` when work needs splitting, dependency cleanup, or a next batch.
+5. Keep progress moving without inventing new product scope.
+
+Away Mode limits:
+
+- Do not change the user's objective.
+- Do not open unrelated work streams.
+- Do not use Gemini, Cursor, or Abacus without explicit permission.
+- If a decision is risky or ambiguous, leave a note in `QUEUE.md` or a handoff instead of guessing.
+
+## Fallback Policy
+
+If Codex or OpenCode fail persistently because of quota, rate limits, token limits, expired sessions, repeated provider errors, or CLI downtime:
+
+1. Detect that the issue is no longer transient.
+2. Add a clear note in `QUEUE.md`, `TASKS.md`, or a handoff.
+3. Reassign the TASK to a Claude-Worker (`Backend` or `Frontend`, based on the repo).
+4. Include the available context so the Claude-Worker can continue instead of restarting from zero.
+
+The priority is continuity. Do not leave tasks looping forever.
+
+## Agents
+
+Check `orchestrator.config.json -> agents`. Each agent has:
+
+- `cli`: the real CLI (`claude`, `codex`, `opencode`, etc.)
+- `defaultRepo`: the default repo key from `repos`
+- `model`: optional model selection
+- `instructionsFile`: the agent-specific Markdown instructions
+
+Default agent summary:
+
+| Name | CLI | Best For |
+| --- | --- | --- |
+| Backend | claude | Backend code through Claude-Worker |
+| Frontend | claude | Broad frontend work through Claude-Worker |
+| Codex | codex | Structured implementation, tests, docs, narrow frontend support |
+| OpenCode | opencode | Exploration, audits, structured reports, scoped implementation |
+| Gemini | gemini | Optional audits and reviews only when explicitly enabled |
+| Cursor | cursor | Optional mechanical bulk edits only when explicitly enabled |
+| Abacus | abacusai | Optional small focused tasks only when explicitly enabled |
+
+## How To Assign Work
+
+Write TASKs in `QUEUE.md` with this format:
+
+```text
+TASK-NNN | short title | Agent | P1 | repo | detailed description
+```
+
+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.
+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. After changing `QUEUE.md`, tell the user to press `R` in the TUI, and `S` if the TUI is paused.
+
+Routing preferences:
+
+1. Start with Codex/OpenCode when a task is clear enough for them.
+2. Keep Claude-Worker available as fallback or extra capacity.
+3. For frontend, use Codex for narrow tasks and Frontend/Claude-Worker for broad UI or complex interaction work.
+4. Use OpenCode for exploration, audits, and scoped implementation.
+5. Do not assign all tasks to Claude just because Claude is the orchestrator.
+
+## Hard Rules
+
+1. Claude-Orchestrator never edits project code directly.
+2. All implementation must go through `QUEUE.md` and worker agents unless the user explicitly overrides this rule.
+3. Never commit or push from worker tasks. Git control belongs to the user.
+4. Use internal subagents only for quick research, not for real project execution.
+5. Keep `QUEUE.md` and `TASKS.md` synchronized.
+6. Track the next `TASK-NNN` to avoid duplicate IDs.
+7. Write a `handoffs/HANDOFF-<date>.md` at the end of meaningful sessions.
+8. Use Engram for durable decisions, bugs, discoveries, and session summaries.
+9. Use `openspec/changes/<change-name>/` for large changes.
+10. Claude remains the final reviewer before work is considered accepted.
+
+## TUI Controls
+
+```bash
+cd <workspace-path>
+node orchestrator.js
+```
+
+- `R`: reload `QUEUE.md`
+- `S`: start or resume
+- `P`: pause
+- `Q`: quit and stop agents
+
+Rate limits are retried near reset time. Completed tasks persist across TUI restarts.
+
+## Session State
+
+Update this section at the beginning and end of meaningful sessions:
+
+- **Latest handoff:** none yet
+- **Next TASK ID:** TASK-001
+- **QUEUE:** summarize current state
+- **Notes:** important context for the next session
+
+## Reference Files
+
+- Project plan: `<projectName>-plan.md`, `PLAN.md`, or `plan.md`
+- Agent instructions: `agents/*.md`
+- Persistent memory rules: `ENGRAM.md`
+- OpenSpec artifacts: `openspec/`
+- Detailed task specs: `TASKS.md`
+- Agent progress: `progress/PROGRESS-<AgentName>.md`
+- Handoffs: `handoffs/HANDOFF-<date>.md`
+- Logs: `logs/`

package/templates/en/PROJECT.md

@@ -0,0 +1,70 @@
+# Project Notes
+
+## Purpose
+
+`agentflow` is a reusable workspace for coordinating multiple coding agents around a real project without placing orchestrator files inside the product repo.
+
+The intended layout is:
+
+```text
+project-workspace/
+  RealProject/
+  orchestrator-realproject/
+```
+
+The real project stays clean. The orchestrator workspace keeps queue, docs, skills, OpenSpec artifacts, memory conventions, logs, and handoffs.
+
+## Product Direction
+
+The package should provide:
+
+- a sibling orchestrator workspace per real project
+- a TUI for live queue execution
+- Claude as orchestrator and final reviewer
+- Codex and OpenCode as default support workers
+- Claude-Workers for fallback, extra capacity, and broad implementation
+- durable memory through Engram conventions
+- OpenSpec artifacts for large changes
+- local skills and agent instructions
+
+## Default Operating Model
+
+1. Install or initialize an orchestrator workspace next to the real project.
+   - Use `--lang en` or `--lang es`, or let the CLI ask interactively.
+2. Configure `orchestrator.config.json`.
+3. Start the TUI.
+4. Open Claude Code inside the orchestrator workspace.
+5. Tell Claude: `Read ORCHESTRATOR.md and start`.
+6. Claude-Orchestrator reads context and asks what to prioritize.
+7. User requests work.
+8. Claude-Orchestrator writes TASKs into `QUEUE.md`.
+9. The TUI launches workers.
+10. Claude-Orchestrator reviews outputs and plans the next batch.
+
+## Important Behavioral Rule
+
+Claude-Orchestrator must not implement project work directly. Even if the user asks for implementation, the orchestrator should create TASKs in `QUEUE.md` and route them to worker agents first.
+
+## Active Default Agents
+
+- `Codex`: structured implementation, tests, docs, narrow frontend support
+- `OpenCode`: exploration, audits, reports, scoped implementation
+- `Backend` / `Frontend`: Claude-Workers used for fallback, extra capacity, or broad backend/frontend work
+
+Gemini, Cursor, and Abacus can remain configured but should not be used unless the user enables them for that session.
+
+## Git Rule
+
+No agent should commit or push unless the user explicitly asks in the current session.
+
+## Future Product Work
+
+Possible next steps:
+
+- binary distribution
+- embedded templates and skills
+- `doctor` command
+- migration/version checks
+- backup and restore
+- stronger tests
+- workspace sync and upgrade flow

package/templates/en/QUEUE.md

@@ -0,0 +1,17 @@
+# Queue
+
+> Format: `id | title | agent | priority | repo | description`
+> Dependencies: append `> after:TASK-NNN` to the description.
+> Comments: lines that start with `#`.
+
+## Pending
+
+# === Example tasks. Delete these before adding real project work. ===
+
+TASK-001 | Create initial backend structure | Backend | P1 | backend | Create base folders, boilerplate, and initial tests
+TASK-002 | Build landing page | Frontend | P1 | frontend | Build a responsive hero section and first viewport
+TASK-003 | Document API endpoints | Codex | P2 | backend | Document REST endpoints in docs/api-reference.md > after:TASK-001
+
+## In Progress
+
+## Completed