skills: add worker-orchestrator and convert old skills to wrappers

skills/execution-agent-planner/SKILL.md

@@ -1,93 +1,47 @@
 ---
 name: execution-agent-planner
-description: Plan execution-agent architecture after project analysis. Use when main is acting as PM/architect and needs to decide whether to keep work with one execution agent or create multiple specialized execution agents, define each agent's role and boundaries, and distribute tasks across them without over-splitting small or tightly coupled work.
+description: Compatibility wrapper for worker planning. Prefer `worker-orchestrator` for the maintained PM/orchestration workflow; use this wrapper when you only need the planning/splitting section.
 ---
 
 # Execution agent planner
 
-Use this skill after the project/problem has been understood well enough to split work.
+This skill is now a **compatibility wrapper**.
 
-## Goal
+The maintained source of truth is:
+- `skills/worker-orchestrator/SKILL.md`
 
-Decide:
-1. whether multiple execution agents are needed
-2. how many are justified
-3. what each agent owns
-4. what should stay with main as PM/reviewer
+## Current role
 
-## Default stance
+Use this wrapper only when the task is specifically about:
+- deciding whether to use one worker or multiple workers
+- defining worker roles / boundaries
+- splitting work before dispatch begins
 
-- Prefer **one execution agent** when work is small, linear, or tightly coupled.
-- Create **multiple execution agents** when the split will reduce confusion or increase throughput.
-- Do not create agents just because the architecture allows it.
+If you need the full workflow, use **`worker-orchestrator`** instead.
 
-## Split triggers
+## Important boundary
 
-Create multiple execution agents when several of these are true:
-- work can proceed in parallel
-- responsibilities are clearly different
-- code/docs/ops/test contexts would otherwise contaminate each other
-- different deliverables need separate review or validation
-- the project spans multiple repos, layers, or operational tracks
-- a single execution agent would become a long-running catch-all bucket
+This wrapper is still only a **planning / architecture aid**.
+It is **not** evidence that OpenClaw / ACP inter-agent communication is stable.
+It does **not** provide transport, routing, or reliable bidirectional communication.
 
-## Avoid splitting when
+## What to read / apply from `worker-orchestrator`
 
-- the task is tiny
-- the task is strongly sequential
-- requirements are still fuzzy
-- one agent would spend most of its time blocked on another
-- the split adds more coordination cost than execution value
+Apply these sections from the unified skill:
+- **Part A — Planning the worker architecture**
+- especially:
+  - Default stance
+  - Split triggers
+  - Avoid splitting when
+  - Planning output
+  - Naming guidance
 
-## Output format
+## Practical note
 
-When using this skill, produce a short plan with:
+Current safe operating model remains:
+- main decides the split
+- workers execute
+- workers report back to main
+- main reports to Tao
 
-### 1) Recommended execution architecture
-- single execution agent
-- or multiple execution agents
-
-### 2) Agent list
-For each proposed execution agent, define:
-- name
-- role
-- scope
-- non-goals / boundaries
-- expected output
-
-### 3) Task allocation
-- what each execution agent should do first
-- what can run in parallel
-- what depends on another agent finishing first
-
-### 4) Main's PM responsibilities
-State what main will keep:
-- requirement clarification
-- prioritization
-- risk calls
-- review / acceptance
-- status updates to Tao
-
-## Naming guidance
-
-Prefer role-based names over vague names.
-Examples:
-- `codex_worker`
-- `frontend_worker`
-- `backend_worker`
-- `qa_worker`
-- `docs_worker`
-- `ops_worker`
-
-Avoid names that do not imply responsibility.
-
-## Delegation rule
-
-Unless the task is truly tiny and can be completed in one short pass, main should avoid doing implementation directly and should assign execution work first.
-
-## Progress discipline
-
-After planning the execution architecture:
-- tell Tao what split you chose and why
-- give the first milestone and ETA
-- report blockers when the split turns out wrong or incomplete
+Do **not** interpret this wrapper as a communication-layer solution.