// Use when orchestrating complex or multi-lane work, decomposing tasks across peers, choosing status/board surfaces, running mesh roundups, or keeping high-level progress visible.
| name | coordination |
| description | Use when orchestrating complex or multi-lane work, decomposing tasks across peers, choosing status/board surfaces, running mesh roundups, or keeping high-level progress visible. |
Coordinate the work shape. Prefer delegation for substantive repo work; small reversible chores may be handled directly when that is the lightest path.
Prefer the user's existing board. Do not invent a new tracker unless the user asks or the work is large enough that status would otherwise be lost.
Useful board columns are simple: Todo, In Progress, Blocked, Review, Done. Entries should describe the outcome, owner, blocker, and next action. Do not mirror every message or tool call.
When the user asks where things stand, use list_peers() and ask relevant peers in parallel. Ask specific questions: blocker, next merge, needed decision. Compile the reply with the highest-impact item first. Keep Telegram/mobile updates short.
Parallel divergent ideation via mesh fan-out. Spawns N frame-shifted peers, scores results, deepens top survivors. Use on open-ended design choices, fuzzy bugs, naming, API surfaces, or explicit /adhd invocation. Skip for syntax, lookups, or closed prompts ("quick", "standard", "canonical").
Use when creating, updating, or explaining a standing Repowire agent folder, worker folder, durable-job executor context, or reusable agent-specific AGENTS.md guidance.
Use when adding, updating, splitting, or reviewing local orchestrator skills for reusable procedures, including controlled self-improvement of the orchestrator.
Use when transferring orchestrator responsibility, summarizing current state for a new peer, recovering after a closed session, or preparing takeover notes.
Use when coordinating PR review, CI triage, second-peer critique, requested-changes loops, merge readiness, or deciding whether implementation needs independent verification.
Use when splitting work across peers, creating or selecting feature worktrees, preventing overlapping edits, or deciding whether to reroute implementation out of the main worktree.