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

skills/worker-orchestrator/SKILL.md

@@ -0,0 +1,245 @@
+---
+name: worker-orchestrator
+description: PM-style orchestration for execution workers. Use when main needs to decide whether to keep work with one worker or split across several, define worker roles/boundaries, dispatch clear task packets, enforce reply discipline, and report progress back to Tao.
+---
+
+# Worker orchestrator
+
+Use this skill when main is acting as **PM / architect / orchestrator** for execution work.
+
+It combines two responsibilities that belong to the same workflow:
+1. **planning** the worker architecture
+2. **dispatching / supervising** the resulting workers
+
+## Status / scope boundary
+
+This is a **PM + orchestration skill**.
+It helps main:
+- decide whether multiple workers are needed
+- define worker scope and ownership
+- dispatch clear handoff packets
+- standardize worker replies
+- keep Tao updated at the right moments
+
+It is **not** a runtime transport fix.
+It does **not** make OpenClaw / ACP inter-agent communication magically stable.
+It does **not** guarantee reliable free-form worker↔worker or agent↔agent conversation.
+
+Current safe interpretation:
+- use it to support the model that now appears practical:
+  - **main → worker → main → Tao**
+- do **not** use it as evidence that worker↔worker direct communication is reliable
+- do **not** use it as a substitute for upstream runtime support
+
+## When to use
+
+Use this skill when:
+- Tao gives main a task that may need delegation
+- main needs to decide whether to use one worker or many
+- main wants cleaner worker boundaries
+- main wants a standard dispatch packet and reply format
+- main wants milestone / blocker / completion reporting discipline
+
+## Goal
+
+Turn a vague implementation request into a controlled execution workflow:
+1. decide the worker split
+2. define responsibilities and boundaries
+3. dispatch clean task packets
+4. supervise milestones / blockers / completion
+5. report upward to Tao in the correct order
+
+---
+
+# Part A — Planning the worker architecture
+
+## Default stance
+
+- Prefer **one worker** when work is small, linear, or tightly coupled.
+- Create **multiple workers** when the split reduces confusion or increases throughput.
+- Do not create workers just because the architecture allows it.
+
+## Split triggers
+
+Create multiple workers 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 worker would become a long-running catch-all bucket
+
+## Avoid splitting when
+
+- the task is tiny
+- the task is strongly sequential
+- requirements are still fuzzy
+- one worker would spend most of its time blocked on another
+- the split adds more coordination cost than execution value
+
+## Planning output
+
+When using this planning section, produce a short plan with:
+
+### 1) Recommended execution architecture
+- single worker
+- or multiple workers
+
+### 2) Worker list
+For each proposed worker, define:
+- name
+- role
+- scope
+- non-goals / boundaries
+- expected output
+
+### 3) Task allocation
+- what each worker should do first
+- what can run in parallel
+- what depends on another worker finishing first
+
+### 4) Main's PM responsibilities
+State what main keeps:
+- 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.
+
+---
+
+# Part B — Dispatch and supervision
+
+## Dispatch packet
+
+When main assigns work to a worker, include these sections:
+
+### 1) Task
+One short statement of the goal.
+
+### 2) Scope
+Specify:
+- repo / path / files if known
+- what area is in bounds
+- what is explicitly out of bounds
+
+### 3) Deliverable
+Define the expected output:
+- code change
+- docs update
+- validation report
+- PR / commit / test result
+- recommendation only
+
+### 4) Constraints
+List non-negotiables, such as:
+- do not change unrelated files
+- do not switch models automatically
+- do not message users directly
+- ask before destructive actions
+
+### 5) Milestone 1 + ETA
+Tell the worker what first checkpoint matters and when main expects the first update.
+
+## Worker response format
+
+Workers should respond compactly with:
+- `status:` accepted | milestone | blocked | failed | done
+- `summary:` short summary
+- `evidence:` files changed/created, commands run, session/log proof, or `none`
+- `risk:` key caveat or `none`
+- `next:` next action or handoff need
+
+Important:
+- A reply without `evidence` is not enough for main to claim the task is truly `in_progress`.
+- `accepted` means the worker has seen the handoff; it does not automatically mean meaningful execution has started.
+
+## Escalate immediately when
+
+A worker should report back to main instead of silently stalling when:
+- permissions are missing
+- the model/tooling is unavailable
+- repo rules block the intended action
+- requirements are contradictory or underspecified
+- the task is crossing role boundaries
+- the ETA has clearly slipped
+- the requested change is riskier or broader than the original handoff suggested
+
+## Silence rule
+
+Workers should not chatter, but should also not disappear.
+
+Default rule:
+- acknowledge briefly
+- do the work
+- report at milestone
+- report immediately on blockers
+
+## Main-to-Tao forwarding rule
+
+Worker updates are not complete until main forwards the state change upward.
+
+When a worker reports any of these:
+- task accepted
+- milestone reached
+- blocked
+- failed
+- completed
+
+main must update Tao **before** continuing with review, commit, release, or re-delegation work.
+
+If a worker has already reported completion and main has not forwarded that state, treat it as a **main process failure**, not as "still in progress".
+
+## Completion rule
+
+A task is not complete just because files changed.
+Completion should include:
+- the requested deliverable exists
+- basic verification happened when relevant
+- blockers or caveats are disclosed
+- main has enough information to review and report upward
+
+## Main's responsibility
+
+Main must not delegate sloppily.
+Before dispatching, main should decide:
+- why this worker is the right worker
+- what the boundary is
+- what review criteria will be used
+- whether the task is small enough that delegation is unnecessary
+
+## Good default tone
+
+- short
+- operational
+- explicit
+- non-dramatic
+
+Prefer a clean task packet over a long motivational speech.
+
+---
+
+## Current practical model
+
+Based on current validation, this skill should be used around this practical orchestration model:
+- **temporary subagents** can act as execution workers and return results to main
+- **ACP Codex workers** can act as execution workers and return results to main
+- **Claude ACP** should be treated as needing clean-sample validation when provider state is healthy
+- **worker↔worker direct communication** is still not something to assume
+
+In short:
+- safe default = **main orchestrates; workers execute; main integrates**
+- unsafe assumption = workers will reliably self-coordinate without main in the loop