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:

aios plan start --title "<objective>" --task "<user need>"
aios plan task <id> --target <path> --allow-write <glob>   # declare ownership
aios plan task <id> --context <ref>                         # per-task context

Independent tasks get empty dependsOn; coupled tasks declare their prerequisite ids. Tasks that share file ownership are NOT independent — merge gate blocks them. After the plan has at least two eligible (pending) tasks, dispatch reads it:

aios work --task "<objective>" --dry-run --json