diff --git a/skills/execution-agent-dispatch/README.md b/skills/execution-agent-dispatch/README.md index 500f0b2..6b2792d 100644 --- a/skills/execution-agent-dispatch/README.md +++ b/skills/execution-agent-dispatch/README.md @@ -1,59 +1,41 @@ # execution-agent-dispatch -A lightweight skill for turning PM decisions into clear worker handoffs. +Compatibility wrapper for the dispatch/supervision half of **`worker-orchestrator`**. -## Why this exists +## Status -It is not enough to have execution agents. -They also need a consistent way to receive work and report results. +This README is kept only as a compatibility aid. +The maintained source of truth is now: -Without that, the system drifts into familiar failure modes: -- vague delegation -- role boundary drift -- workers doing too much or too little -- silent blocking -- messy result reporting +- `skills/worker-orchestrator/SKILL.md` -This skill exists to standardize the handoff layer between **main** and execution agents. +## What this wrapper still means -## What it standardizes +Use `execution-agent-dispatch` only when you specifically want the **dispatch / handoff / reporting-discipline** half of the orchestration workflow: -- the task packet main sends to a worker -- the result format a worker returns -- when a worker must escalate instead of staying silent -- milestone / ETA discipline for delegated work +- turn a worker plan into a clear task packet +- standardize worker reply format +- enforce milestone / blocker / completion reporting +- keep main-to-Tao forwarding discipline explicit -## Core idea +## What it is not -A good worker handoff should answer: -1. What exactly should be done? -2. What is out of bounds? -3. What does success look like? -4. When should the worker report back? -5. What should trigger escalation? +This wrapper is **not**: +- a runtime transport fix +- evidence that worker↔worker or agent↔agent communication is stable +- a substitute for upstream OpenClaw / ACP runtime support -## Recommended task packet +## Preferred modern usage -- Task -- Scope -- Deliverable -- Constraints -- Milestone 1 + ETA +If the task involves both: +- deciding the worker split +- and dispatching / supervising workers -## Recommended result packet +then use **`worker-orchestrator`** directly. -- `status:` accepted | milestone | blocked | failed | done -- `summary:` ... -- `evidence:` ... -- `risk:` ... -- `next:` ... +## Practical takeaway -## Added operational aids - -- `CHECKLIST.md` — pre-dispatch / post-dispatch / evidence-gate checklist for main -- `FAILURE_TEMPLATE.md` — compact template for documenting launch failure, stall, or misreporting cases - -## Notes - -This is a dispatch / coordination skill, not an implementation skill. -It works best after `execution-agent-planner` has already decided which workers should exist and what they should own. +Current safe operating model remains: +- main dispatches workers +- workers execute and report back to main +- main integrates and reports to Tao diff --git a/skills/execution-agent-planner/README.md b/skills/execution-agent-planner/README.md index 4f3371d..e38e988 100644 --- a/skills/execution-agent-planner/README.md +++ b/skills/execution-agent-planner/README.md @@ -1,60 +1,42 @@ # execution-agent-planner -A lightweight skill for deciding when a project should stay with one execution agent and when it should be split into multiple specialized execution agents. +Compatibility wrapper for the planning half of **`worker-orchestrator`**. -## Why this exists +## Status -Once main takes the PM / architect role, a new question appears: +This README is kept only as a compatibility aid. +The maintained source of truth is now: -- Should this project go to one execution agent? -- Or should it be split across several workers with different roles? +- `skills/worker-orchestrator/SKILL.md` -Without a repeatable rule, it is easy to drift into two bad extremes: -- **under-splitting**: main or one worker becomes a catch-all bucket -- **over-splitting**: too many agents, too much coordination, not enough real progress +## What this wrapper still means -This skill exists to keep that decision disciplined. +Use `execution-agent-planner` only when you specifically want the **planning / splitting** half of the orchestration workflow: -## What it helps decide +- decide whether work should stay with one worker or split into several +- define worker roles and boundaries +- avoid over-splitting or under-splitting +- decide what stays with main as PM / reviewer -- whether multiple execution agents are justified -- how many workers to create -- what each worker should own -- what should remain with main as PM / reviewer -- how to split tasks without creating coordination theater +## What it is not -## Core rule +This wrapper is **not**: +- a communication-layer fix +- evidence that OpenClaw / ACP inter-agent communication is stable +- a transport or routing solution -Start simple. +## Preferred modern usage -- If work is small, linear, or tightly coupled: keep one execution agent. -- If work is parallelizable, role-distinct, and context-heavy: split into multiple execution agents. +If the task involves both: +- planning the worker architecture +- and dispatching / supervising workers -## Good reasons to split +then use **`worker-orchestrator`** directly. -- frontend / backend / docs / ops / QA are genuinely different tracks -- tasks can run in parallel -- one worker would otherwise mix too many contexts -- outputs need separate validation paths -- the project spans multiple repos or operational domains +## Practical takeaway -## Bad reasons to split - -- the project only sounds important -- requirements are still fuzzy -- tasks are tiny -- most agents would just wait on each other - -## Suggested output - -A good plan should answer: -1. Do we keep one execution agent or use several? -2. What is each agent called? -3. What does each agent own? -4. What does main keep as PM? -5. What is milestone 1? - -## Notes - -This is not an implementation skill. -It is a planning skill for execution architecture. +Current safe operating model remains: +- main plans +- workers execute +- workers report back to main +- main integrates and reports to Tao