Menú
How the Auto-DAG task lifecycle works — task states, dependency resolution, and common pitfalls
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
How the multi-backend adapter system works — AgentAdapter interface, ACP protocol, session resume, and how to add new provider adapters
When debugging why an agent has the wrong provider/model, or when modifying agent creation or delegation flows.
How to get agents to use group chats for peer coordination in flightdeck-based crews. Covers hub-and-spoke anti-pattern, auto-grouping triggers, and file-lock-linked groups. Use when setting up multi-agent crews with 3+ agents or diagnosing why agents aren't collaborating directly.
When fetching from the `/coordination/activity` API and you only need specific action types (e.g., `progress_update`, `task_completed`, `delegated`).
When fetching activity data for UI display, or debugging why activity-based features show empty/stale data.
Architecture decisions and patterns from Flightdeck development (Phases 2–4). Covers feature architecture, state management, component patterns, and API design.
| name | auto-dag-task-lifecycle |
| description | How the Auto-DAG task lifecycle works — task states, dependency resolution, and common pitfalls |
Tasks in the DAG follow a state machine: pending → ready → running → done/skipped/failed.
| State | Meaning |
|---|---|
pending | Dependencies not yet satisfied |
ready | All dependencies satisfied, files available for lock |
running | Delegated to an agent |
done | Completed successfully |
skipped | Skipped (e.g., superseded by another task) |
failed | Failed after attempts |
The resolveReady() method promotes pending tasks to ready when their dependencies complete. It is called reactively inside completeTask(), skipTask(), and cancelTask().
When adding tasks whose dependencies are already done, the task must be set to ready not pending. The resolveReady() method must also be called after batch task creation (declareTaskBatch) to catch tasks with pre-completed deps.
Tasks added after their deps complete can get stuck in pending if dependency satisfaction isn't checked at creation time. findReadyTask() has a safety net that auto-promotes stuck pending tasks, but this is a fallback — not the primary mechanism.
After calling declareTaskBatch(), always call resolveReady() to promote any tasks whose deps are already satisfied.
