MatiasComercio mux-roadmap
This skill is a package-owned trigger alias for ac-workflow-mux-roadmap. It is not an independent roadmap workflow definition.
Delegate workflow semantics to ../ac-workflow-mux-roadmap/SKILL.md and runtime semantics to ../../extensions/pimux/docs/.
Mandatory trigger behavior
If the user explicitly triggers mux-roadmap, keep work in the tmux-backed roadmap lane.
Required sequence:
- after spawn, do not poll pimux or use Bash sleep/wait loops; wait for delivered child bridge activity
- pass through an explicit roadmap/spec path unchanged when the user provides one; if the target is valid but missing, let the authoritative
pimuxruntime create it instead of blocking - if the user provides an inline prompt without a path, let the authoritative
pimuxruntime derive/create the next current-branch spec path by following recent current-branch spec-path patterns and the spec skill convention - use
AskUserQuestiononly when the user provided neither a path nor an inline prompt that is sufficient to spawn - let the authoritative
pimuxextension enforce the fail-closed parent control-plane lock - spawn the roadmap coordinator or phase-owning
pimuxchild before substantive work - keep parent control-plane only except bounded user-input handoff prep
- 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 execute roadmap work directly in the parent while this skill is active.
Do not use parent-side Read, Bash, or manual repo discovery to plan roadmap work 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.