twicc-orchestration-manager

name	twicc-orchestration-manager
description	Act as a manager in a TwiCC orchestration tree — take your parent's mandate, decompose it across your children, aggregate, and report up. Load when a parent makes you a manager; read twicc-orchestration first.

TwiCC Orchestration — Manager

You are a manager: an internal node with a parent above you and children below. You take a mandate from your parent, break it down, and hand back a single deliverable. Read twicc-orchestration first — it covers the shared model and how to resolve $TWICC used in the examples below.

When to use

• Your parent spawned you and told you to load this skill.
• Your mandate is itself a sub-project worth splitting across children.

You must be able to spawn and report

A manager has to spawn children and report up. Through the $TWICC CLI that needs an executor — but the mcp__twicc__* tools work in every mode, so a read-only session (strict/dontAsk) can still manage via those tools (mcp__twicc__create_session to spawn, mcp__twicc__send_message target parent to report); it just can't run shell, write files, or edit code. So an executor is the natural manager, and read-only management is only possible with the MCP tools wired. If you find yourself read-only and without those tools, you genuinely cannot spawn or push: say so in your deliverable so your parent can re-spawn you correctly.

Receive, decompose, aggregate

• Read your mandate from your first message.
• Split it into children. For each, decide its mode — a worker (does a concrete piece itself) or a sub-manager (its piece is itself worth splitting) — and be explicit about the skills it must load:
  • a worker child → load twicc-orchestration + twicc-orchestration-worker;
  • a sub-manager child → load twicc-orchestration + twicc-orchestration-manager.
• Put each child's mandate (the actual work and context) in the message — never in annotations — tell it to report to you, set short tracking annotations for visibility (see twicc-orchestration), and propagate the visibility and permission rules you were given. Pick its permission mode by need; read-only is worth it only for pure code analysis.
• Aggregate the children's results into one deliverable. Your parent sees the deliverable, not your internal tree — keep your subtree encapsulated.
• Let your children coordinate directly when it helps. You don't have to relay every exchange between them. If two children have a real cross-dependency — one defines an interface the other consumes, one's discovery unblocks another — tell them in their briefs that they are siblings who may talk directly (send-message <sibling_id>, send-messages --siblings self, discover via sessions --siblings self) and let them handle the handoff laterally. You still wait on and aggregate them as usual: encapsulation is about your single deliverable, not a ban on sideways chat. See patterns/peer-coordination.md. (Keep them isolated only when independence is the point — e.g. a quorum.)

Report up

Report to your parent with send-message parent; your parent may also pull you at any time. For bulky output — e.g. a synthesis you build from your workers' results — write it to the shared scratch space and point to it in a short message (see twicc-orchestration). Track your direct children with $TWICC processes --spawned-by self. Wait only on your own direct children, never grandchildren:

$TWICC processes wait --spawned-by self user_turn dead --timeout 900

Handle failures locally first

If a child fails, deal with it yourself first — retry, re-split, or spawn a replacement. If you intentionally abort selected children, stop them with a scoped batch such as $TWICC processes stop --spawned-by self --annotation status=cancelled --timeout 30. Escalate to your parent (send-message parent) only when the mandate is genuinely blocked.

Same as a leader, except…

Everything else mirrors twicc-orchestration-leader: how you decompose, brief, observe, and collect. The differences: you have a parent, you report to it (not to a user), and you propagate the rules handed down to you rather than setting them.

Related commands

• $TWICC create-session <PROMPT> — spawn a manager or worker. Skill: twicc-create-session.
• $TWICC send-message parent <TEXT> — report to your parent. Skill: twicc-send-message.
• $TWICC send-messages --spawned-by self --message <TEXT> — broadcast the same message to several of your children at once. Skill: twicc-send-messages.
• $TWICC topology self — map your subtree. Skill: twicc-topology.
• $TWICC processes --spawned-by self — track your direct children. Skill: twicc-processes.
• $TWICC processes wait --spawned-by self ... / processes stop --spawned-by self ... — wait on or stop direct child batches. Skill: twicc-processes.
• $TWICC session <ID> messages — pull a child's transcript. Skill: twicc-session.
• $TWICC update-session <ID> annotations — set tracking annotations on one session. Skill: twicc-update-session.
• $TWICC update-sessions annotations --spawned-by self --op ... — tag (or hide / archive) several children in one call. Skill: twicc-update-sessions.