aios-work-dispatch

# AIOS Work Dispatch Use this Skill when deciding whether current coding task should enter `aios work` parallel dispatch. It explains routing; it does not replace current AIOS workflow policy or Rex Command. ## Trigger eligibility Use `aios work` candidate route only when all conditions hold: 1. Current AIOS disposition is `planned`. 2. Task decomposes into at least two independently executable work items. 3. Each work item has explicit owner/path boundary and observable acceptance criteria. 4. Work-item file ownership does not overlap. 5. Work items do not require strict predecessor ordering. 6. Task is not one continuous resumable objective. If any condition is unproven, keep execution serial and do not launch `aios work`. ## Do not use - Small local change or typo: use current single-agent route. - Coupled edits or strict ordered phases: use current Provider or `aios orchestrate`. - One long resumable objective: use `aios harness`. - Status, history, or observability only: use `aios team`. - Review-only request: do not dispatch implementers. - Unclear ownership, missing acceptance criteria, or unknown client readiness: stop and clarify or remain serial. ## Required execution sequence ### 0. Plan the decomposition first (user need -> work items) `aios work` decomposes from a structured plan when one is active, otherwise from the `--context` string. Plan first so the engine can use real dependencies and ownership instead of guessing: ```bash aios plan start --titl...