multi-agent-delegationlisted

# Multi-Agent Delegation Unsure whether delegation is the right structure at all? Start at mega-orchestration:orchestrating, the decision root; this skill executes the delegation route it picks. ## The Idea The lead keeps the broad context, plans and decomposes the work, does cheap bulk reads, and owns final integration and commits. Narrow, specialized work goes to whichever model is best suited for it. Routing lives in two layered files: `models.toml`, the model catalog (who leads, the tier scale and its purposes, the providers with their tier maps and channel data, the ship floor), and `delegates.toml`, the routing (which provider handles which role, at which tier and effort, under which independence, evidence driver, and run preset). Every table name is in references/dispatch-contract.md. Both resolve the same way: a project `.megapowers/<file>` or user `~/.config/megapowers/<file>` layer overrides the shipped copy per key, so a new model release is one tier-map line in a file that survives plugin updates. `scripts/delegate-resolve --where` shows the active layers. Edit an override layer to change routing: the skill, the browser delegate, and the session-start catalog block read the config live. What the docs claim about routing is pinned by `scripts/tests/delegation-docs.test.sh`. The nine roles: plan_review, code_review, small_impl, visual, browser_test, visual_verify, verify, judge, council_member. ## Resolving a Route `scripts/delegate-resolve <role>` resolves