01
What this skill does
Use this skill for non-trivial multi-step work that needs coordinated parallel or dependent workstreams. After explicit invocation, the root parent builds a task and decision graph, assigns one owner per material decision domain and write boundary, appoints bounded subplanners only for independently decomposable subtrees, uses owned single-writer ephemeral documents when hierarchy or context handoffs need shared memory, schedules ready work event by event, routes conflicts, and retains final integration and cleanup ownership. Invocation is explicit-only: a user must invoke `$multitask-coordinator`; matching prompts do not activate it automatically.
02
When to use it
- 01Coordinating parallel and dependent work through an explicit task and decision graph.
- 02Delegating exclusive decision domains to recursive subplanners with bounded capacity and scope.
- 03Sharing accepted decisions and handoffs through owned, single-writer ephemeral documents when needed.
- 04Preventing decision split-brain, stale contracts, and overlapping writes in large repositories or migrations.
- 05Keeping healthy workers uninterrupted while accepted results unlock dependent work.
- 06Auditing hierarchical orchestration for ownership drift, uncontrolled recursion, contention, or verification gaps.
03
How it works
- 01
Frame the root specification, then read applicable rules and dirty state before dispatching writers.
- 02
Build a task and decision graph with dependencies, owners, stable inputs, scopes, evidence, and acceptance criteria.
- 03
Create one owned ephemeral shared-memory root only when hierarchy, context handoffs, or repeated discoveries justify it.
- 04
Keep small or tightly coupled work with the current planner; appoint a subplanner only for an exclusive decomposable subtree.
- 05
Freeze consumed decisions and contracts, then dispatch useful ready work within ownership, isolation, and integration capacity.
- 06
Inspect terminal evidence incrementally, route conflicts by type, and unlock dependents immediately after acceptance.
- 07
Verify the integrated result, decision consistency, and residual risk under root-parent ownership.
04
What you get back
- 01A task and decision graph with explicit hierarchy, dependencies, decision owners, and write boundaries.
- 02An optional marker-owned ephemeral memory root with exact paths and one writer per document.
- 03Subplanner and worker contracts with delegation authority, stable inputs, scope, evidence, and validation.
- 04An evidence-backed synthesis of accepted work, routed conflicts, stale inputs, blockers, residual risks, and final verification.
05
Important boundaries
- 01Do not dispatch a writer before repository rules, dirty state, decision ownership, and write ownership are known.
- 02Do not assign more than one owner to a material decision domain or shared write boundary.
- 03Do not let an ordinary worker delegate; only an explicitly appointed subplanner receives descendant capacity and scope.
- 04Do not scan for, broadly inject, concurrently edit, or unsafely delete ephemeral shared-memory documents.
- 05Do not cancel, restart, reassign, or send unsolicited follow-ups to healthy workers.
- 06Do not accept worker output as fact without reviewing changed files, artifacts, command output, or other concrete evidence.
06