// Run parallel or isolated subagents for independent subtasks (research, parallel analysis, one-shot transforms) to avoid bloating the main context.
| name | delegate |
| description | Run parallel or isolated subagents for independent subtasks (research, parallel analysis, one-shot transforms) to avoid bloating the main context. |
Use when the work is self-contained and iteration isn't needed: codebase exploration, bulk research across many files, independent subtasks that can run in parallel, one-shot refactors with a clear spec.
Do not use for iterative work needing back-and-forth, or for tasks already mid-flight in the main context.
The subprocess inherits OPENAI_API_KEY, MODEL, OPENAI_BASE_URL and has no prior history. The prompt must be fully self-contained:
Spawning subagents: use node "$MI_PATH" — the harness sets MI_PATH automatically:
node "$MI_PATH" -p '<prompt>'
Sequential (one task, wait for result):
node "$MI_PATH" -p 'Read /abs/path/foo.py and list every function that touches the database. Print one per line as file:line name.'
stdout becomes the tool result. Use timeout= on the bash call if the task could hang.
Parallel (multiple independent tasks):
node "$MI_PATH" -p '<prompt A>' # with bg=truthy -> pid:A log:/tmp/mi-A.log
node "$MI_PATH" -p '<prompt B>' # with bg=truthy -> pid:B log:/tmp/mi-B.log
Collect each pid and log. Background children are detached (the harness calls unref) so wait will not find them — poll with kill -0 <pid> 2>/dev/null instead (exit 0 = still running, exit 1 = finished).
Reading long logs: subagent logs grow large. Do NOT cat the full log blindly — instead:
tail -n 50 /tmp/mi-A.log to see the final output and whether the agent concludedgrep -n "RESULT\|ERROR\|DONE\|Traceback" /tmp/mi-A.log to surface key lines quicklywc -l /tmp/mi-A.log to know total size before committing to a full read/tmp/mi-A.out), read that instead — it's why you ask for oneAlways prefer telling each subprocess to write a compact result file under /tmp/mi-* so you don't have to parse transcript noise.
Keep prompts short and specific. A vague delegation wastes a whole subprocess.
Answer questions about how 'mi' works, write new tools, or modify the harness. Use for "how do you work", "write a tool", "add a tool", "create a tool", "extend yourself", "edit yourself", "what tools do you have", or any introspection/modification of the running agent.
Scan the codebase and classify every fact by lifecycle stage — tag @draft, @spec, or @implemented based on what the code actually shows. Add missing facts, fix inaccurate ones, remove obsolete ones. Use when asked to discover facts, bootstrap or update a fact sheet, scan the codebase for truths, sync facts to match the code, or audit the fact sheet for accuracy.
Operate on @spec facts — implement them in code, then tag @implemented. Use when asked to implement facts, implement the spec, build from the fact sheet, make facts true, or work through unimplemented requirements.
Operate on @draft facts — collaboratively refine them into precise, actionable @spec facts. Resolve ambiguities, fill gaps, eliminate contradictions, and sharpen labels until every fact is ready to implement. Use when asked to refine facts, clarify the spec, review facts for quality, or "work on facts" with the user.
Manage .facts files — atomic, validatable truth statements about a project. Install, check, list, add, edit, remove, and lint facts via the CLI. ALWAYS read this skill when the user mentions facts in any capacity.
Write a new SKILL.md to teach yourself a procedure for a recurring task. Use when asked to "write a skill", "create a skill", "add a skill", "remember how to X", "make a procedure for X", or when you notice a task pattern worth recalling in future sessions.