docs: convert legacy execution-agent readmes to wrappers

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

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