orchestrator-worker

Use the orchestrator/worker pattern: an orchestrator on a capable model decomposes the plan into bounded tasks, then launches workers on the cheapest capable model per task. Each worker gets a prompt template with the plan issue, its task issue, and acceptance criteria.

Store the plan as a labeled issue in an external task tracker rather than chat history. A fresh session calls todo_list filtered by the plan label, reads the plan body and child task states, and resumes from the authoritative record without any local plan files.

Use process-verified task claims: a worker claims its task before starting, and the claim is bound to its OS process (host, pid, start time). Other sessions check claim status first and skip tasks with a live claim instead of editing their files.

Yes, when the tracker is exposed as an MCP server registered in each tool's config, with a CLI fallback for tools that cannot reach MCP directly. Each tool can play orchestrator or worker against the same plan and task issues.

Skip it for single-turn, single-file, quickly-resolved work where scaffolding a plan is pure overhead. Even for planned work, full delegation with workers is only warranted when tasks are independent, context-heavy, or worth the coordination cost.

Cache findings as research-labeled issues with a covers list of file paths and content hashes. Before new research, re-hash the listed files: matching hashes mean the cached findings are reusable, and only changed files need narrow re-verification.