customer-education-workshops / rules

---
description: Do not wrap Ledgerly /multitask in a single implementer Task
alwaysApply: true
---

# No wrapper for /multitask

The parent chat **is** the coordinator. Do not launch a Task whose job is “implement this plan,” “execute the runbook,” or “dispatch the workers.” That wrapper is not an implementer.

Launch mechanics live in `.cursor/skills/dispatch-subagents/SKILL.md`. Slice-specific workers, files, and verify steps live in the plan (e.g. `.cursor/plans/resolve-dispute.md`).

## Dispatch

- First Task calls are the named parallel workers (one isolated Task per workstream / worktree).
- Put owned files, contract, constraints, and verify steps **in each worker’s prompt**. Do not start a sibling later “so it has context.”
- Do not add an extra agent whose only job is to re-dispatch, write tests, or own the whole slice.
- Dependent steps (apply, review, verify) wait until those workers finish. They are not a reason to wrap the workers.

```
# ❌ BAD — one Task around the plan
Task: “Read the attached plan and implement it. You may split into subagents.”

# ✅ GOOD — coordinator launches the named rows
Task: owns <file A> only
Task: owns <file B> only
```

A typed worker (`api-instrumenter`, `ledgerly-reviewer`, `dispute-verifier`) is still one named job. It is not a stand-in for “do the whole plan.”

## Stay on the main worktree

The parent chat stays in the primary checkout on `main`. Do not `git checkout` a worker branch there.

Do not call `move_agent_to_root` or `SetActiveBranch` for a worker worktree or branch. If a tool would switch this chat’s root, skip it and keep the main path.

Read worker diffs from the linked worktree paths. Apply them later, from `main`, in the plan’s order.