How do I install the Detect Multi Task skill?

Run npx skillmds@latest add aibot88/detect-multi-task in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Detect Multi Task safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Detect Multi Task?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Detect Multi Task free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Detect Multi Task?

aibot88 (@aibot88) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Detect Multi Task by aibot88 — Agent Skill

Name: Detect Multi Task
Rating: 4.666666666666667 (3 reviews)
Author: aibot88

Detect Multi Task

Detects whether a user task contains multiple independent subtasks and splits it into a JSON array. Internal helper for orchestrate Phase 0.5; uses session credentials (no API key). Always returns STRICT JSON {is_multi, tasks[]} with cap N=5.

aibot88 Updated Sep 9, 2026 3 repo stars

File contents

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

A task is single when:

One imperative goal, even if it requires multiple steps (e.g., "refactor auth and add tests" — tests are subordinate to the auth refactor, single domain)
Multiple verbs but same target file/module (e.g., "investigate and fix the cache bug" — same domain)
A question or open-ended exploration (e.g., "how should I structure the API?")

A task is multi when:

2+ independent goals targeting DIFFERENT domains or modules (e.g., "refactor auth; add Stripe webhook; debug pgvector index" — three different subsystems)
Explicit separators (;, numbered list, \n\n, "and also", "plus", "além disso")
Different verb-object pairs with no shared object (e.g., "update the dashboard chart and migrate the order schema")

When uncertain, lean towards single — splitting a single task hurts more than treating two tasks as one (the user can re-invoke orchestrate per task).

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/trailing whitespace per subtask
Each entry MUST be a non-empty string
For single-task, tasks[] MUST contain exactly ONE entry: the original task verbatim
For multi-task, tasks[] MUST contain 2 to 5 entries

Examples (for your reasoning, not output)

Input: "refactor the auth middleware" → {"is_multi": false, "tasks": ["refactor the auth middleware"]}

Input: "refactor auth; add Stripe webhook; debug pgvector index" → {"is_multi": true, "tasks": ["refactor auth", "add Stripe webhook", "debug pgvector index"]}

Input: "how should I structure the new payment API?" → {"is_multi": false, "tasks": ["how should I structure the new payment API?"]}

Input: "investigate and fix the cache corruption bug" → {"is_multi": false, "tasks": ["investigate and fix the cache corruption bug"]} (same domain, subordinate verbs)

Input: "melhorar a feature de pagamento e ajustar o webhook do Stripe" → {"is_multi": true, "tasks": ["melhorar a feature de pagamento", "ajustar o webhook do Stripe"]} (preserve pt-BR verbatim)

Validation downstream will reject malformed output (missing keys, non-string entries, empty array, >5 entries) and fall back to single-task path.

---name: detect-multi-taskdescription: Detects whether a user task contains multiple independent subtasks and splits it into a JSON array. Internal helper for orchestrate Phase 0.5; uses session credentials (no API key). Always returns STRICT JSON {is_multi, tasks[]} with cap N=5.--- # 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 A task is **single** when: - One imperative goal, even if it requires multiple steps (e.g., "refactor auth and add tests" — tests are subordinate to the auth refactor, single domain) - Multiple verbs but same target file/module (e.g., "investigate and fix the cache bug" — same domain) - A question or open-ended exploration (e.g., "how should I structure the API?") A task is **multi** when: - 2+ independent goals targeting DIFFERENT domains or modules (e.g., "refactor auth; add Stripe webhook; debug pgvector index" — three different subsystems) - Explicit separators (`;`, numbered list, `\n\n`, "and also", "plus", "além disso") - Different verb-object pairs with no shared object (e.g., "update the dashboard chart and migrate the order schema") When uncertain, lean towards **single** — splitting a single task hurts more than treating two tasks as one (the user can re-invoke orchestrate per task). ## 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/trailing whitespace per subtask - Each entry MUST be a non-empty string - For single-task, `tasks[]` MUST contain exactly ONE entry: the original task verbatim - For multi-task, `tasks[]` MUST contain 2 to 5 entries ## Examples (for your reasoning, not output) Input: `"refactor the auth middleware"` → `{"is_multi": false, "tasks": ["refactor the auth middleware"]}` Input: `"refactor auth; add Stripe webhook; debug pgvector index"` → `{"is_multi": true, "tasks": ["refactor auth", "add Stripe webhook", "debug pgvector index"]}` Input: `"how should I structure the new payment API?"` → `{"is_multi": false, "tasks": ["how should I structure the new payment API?"]}` Input: `"investigate and fix the cache corruption bug"` → `{"is_multi": false, "tasks": ["investigate and fix the cache corruption bug"]}` (same domain, subordinate verbs) Input: `"melhorar a feature de pagamento e ajustar o webhook do Stripe"` → `{"is_multi": true, "tasks": ["melhorar a feature de pagamento", "ajustar o webhook do Stripe"]}` (preserve pt-BR verbatim) Validation downstream will reject malformed output (missing keys, non-string entries, empty array, >5 entries) and fall back to single-task path.

Frequently asked questions