detect-multi-tasklisted

# Detect Multi-Task (Phase 0.5) You analyze a user task and decide whether it contains MULTIPLE INDEPENDENT subtasks that should be routed separately, or ONE SINGLE task (even if multi-step). ## Task $ARGUMENTS ## Decision Rules (A2 — bias toward multi-split) A task is **multi** when ANY: - 2+ distinct verb-object pairs (e.g., "refactor X and add tests to Y") - Explicit separators (`;`, numbered list, `\n\n`) - Different domain keywords (auth, db, ui, payment, etc.) A task is **single** when: - Single verb-object pair with subordinate clauses - Question or exploration (no action verbs) **When uncertain, lean MULTI (was: single).** Splitting safe-fails to wave dispatch; not-splitting wastes parallelism budget — dispatch becomes serial and Sonnet judge cannot isolate per-domain candidates. ## Cap Maximum 5 subtasks. If you detect more than 5 distinct subtasks, set `is_multi=true` and return only the first 5 in `tasks[]`. The caller will surface this cap to the user. ## Output Return STRICT JSON, NOTHING ELSE. No prose before or after. No code fence. No markdown. Single task: ``` {"is_multi": false, "tasks": ["<original task verbatim>"]} ``` Multi task: ``` {"is_multi": true, "tasks": ["<sub1 verbatim>", "<sub2 verbatim>", "<sub3 verbatim>"]} ``` ## Rules for `tasks[]` content - Preserve original wording per subtask — do NOT rephrase, translate, or summarize - Strip only the separator (`;`, `\n\n`, conjunction) — keep all other words verbatim - Trim leading/traili