mux
This skill is a package-owned trigger alias for ac-workflow-mux. It is not an independent workflow definition.
Delegate workflow semantics to ../ac-workflow-mux/SKILL.md and runtime semantics to ../../extensions/pimux/docs/.
Mandatory trigger behavior
If the user explicitly triggers mux, the parent must actually run through pimux.
Required sequence:
- after spawn, do not poll pimux or use Bash sleep/wait loops; wait for delivered child bridge activity
- treat the authoritative
pimuxextension as the fail-closed parent control-plane lock - prepare bounded handoff from the user request only
- spawn the authoritative
pimuxchild before substantive analysis - keep the parent control-plane only; use
AskUserQuestiononly for explicit user clarification - after spawn, run notify-first rather than poll-first: do not call
status,capture,tree,list, oropenon the happy path - after a child progress report, use at most one
send_messageif input is needed, then wait again - use
status/capture/tree/list/openonly for explicit live inspection, suspected stall/protocol violation/failure, or the inactivity watchdog - after terminal settlement, do one final
pimux statusverification and then advance
Do not satisfy mux requests by directly doing domain work in the parent.
Do not use parent-side Read, Bash, or repo inspection to figure out the task before spawn.
Do not poll pimux or use Bash sleep/wait loops; wait for delivered child activity, and treat status / capture / tree / list / open as recovery-only.