skills: add execution-agent planning workflow

MEMORY.md

@@ -21,6 +21,8 @@
   - Default delegation rule: unless a task is truly tiny and can be finished in one short pass, **main should not default to personally coding/editing files**; implementation work should be delegated to **codex_worker** first.
   - Good candidates for main to do directly: tiny edits, very small linear fixes, or short actions that are not worth execution-agent handoff.
   - For complex projects, create more specialized agents as needed (e.g. frontend/backend/test/ops/docs/data) instead of overloading one agent.
+  - Create multiple execution agents when work is meaningfully parallel, responsibilities are different, contexts are likely to contaminate each other, or independent validation/release tracks are needed.
+  - Avoid over-splitting for tiny, highly coupled, or poorly defined tasks.
   - This is the **current default pattern**, but Tao may change the rules as needs evolve.
 
 ## 4) ACP/Codex delegation constraints

memory/2026-03-07.md

@@ -57,4 +57,5 @@
 - Preference: `codex_worker` should avoid automatic fallback; if GPT-5.4 is unavailable, report to Tao for model decision.
 - Preference: execution agents should get the strongest execution model; main should remain strong for PM/summary work, but not necessarily do the coding itself.
 - New delegation rule clarified: unless work is truly tiny and can be finished in one short pass, main should avoid personally editing/coding and should delegate implementation to `codex_worker` first.
+- New agent-splitting rule clarified: create multiple execution agents when work is parallelizable, responsibilities differ, contexts would otherwise get mixed, or separate validation/release tracks are needed; avoid splitting tiny or tightly coupled work.
 - This architecture is the current default, but Tao may revise it as needs change.

skills/execution-agent-planner/README.md

@@ -0,0 +1,60 @@
+# 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.
+
+## Why this exists
+
+Once main takes the PM / architect role, a new question appears:
+
+- Should this project go to one execution agent?
+- Or should it be split across several workers with different roles?
+
+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
+
+This skill exists to keep that decision disciplined.
+
+## What it helps decide
+
+- 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
+
+## Core rule
+
+Start simple.
+
+- 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.
+
+## Good reasons to split
+
+- 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
+
+## 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.

skills/execution-agent-planner/SKILL.md

@@ -0,0 +1,93 @@
+---
+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.
+---
+
+# Execution agent planner
+
+Use this skill after the project/problem has been understood well enough to split work.
+
+## Goal
+
+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
+
+## Default stance
+
+- 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.
+
+## Split triggers
+
+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
+
+## Avoid splitting when
+
+- 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
+
+## Output format
+
+When using this skill, produce a short plan with:
+
+### 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