docs: convert legacy execution-agent readmes to wrappers

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