MegaTask

Most of the time you describe one piece of work and RoboCo builds it. Sometimes you have several things you want done at once — and they aren't always in the same repository. A MegaTask lets you describe the whole set in a single intake chat and hand it off as one batch that the company sequences and builds for you.

The motivating example: you want to ship a change to a SaaS app, the open-source core engine it depends on, and a framework adapter — three repositories that don't share a codebase. That's one MegaTask.

Starting a MegaTask

The intake modal has three scopes:

• Single cell — one task in one project.
• Board-led — a feature spanning the cells of one product.
• MegaTask — several tasks across the projects you pick.

Choose MegaTask and check every repository the work spans (pick at least two). The intake agent clones and reads all of them, interviews you exactly as usual, and then — instead of proposing one draft — proposes the whole batch at once: one task per piece of work, each already assigned to the project it belongs to.

How the batch is sequenced

For each task it proposes, the agent declares a small collision surface: which files or directories it will touch, whether it adds a database migration, and whether it edits a widely-shared component. RoboCo turns those surfaces into conflict-free waves with a deterministic analyzer — no guesswork:

• Tasks that touch the same files are serialized (the more important one first).
• Tasks that add a migration run in a serial chain, never two at once.
• A task that edits a shared surface runs after the tasks it overlaps.
• Everything else runs in parallel.

Each root-subtask is stamped with a sequence number derived from its wave — this is the same general sibling-ordering mechanism every parent's subtasks use (see the task lifecycle), not something MegaTask-specific. It's enforced at the claim chokepoint itself, not just by wiring dependency edges: a root-subtask in wave N strictly cannot be claimed while any wave-(N-1) root-subtask is still non-terminal. Two root-subtasks in the same wave — no file overlap, nothing shared — carry the same sequence and run fully in parallel. A cancelled task still releases the wave behind it.

What gets created

When you confirm, RoboCo creates one umbrella task that groups the batch, and one root-subtask per piece of work:

The umbrella is the batch's single review-and-approve unit. It does no git of its own — it spans repositories that have no common master, so there is no mega-PR. Each root-subtask is a normal piece of work in its own repository, with its own branch and its own pull request, coordinated by the Main PM down to the cells exactly like any other task. The umbrella finishes only when every task in it is done.

The two start buttons

Like a single task, a MegaTask offers two start paths:

• Board review & Start — the Product Owner and Head of Marketing review the whole batch first (they see every task and can adjust scope). The work is held until you approve the umbrella, then released wave by wave.
• Approve & Start — the batch goes straight to the Main PM and the first wave dispatches immediately.

Either way you review and approve the batch once, not task by task. After it launches, the umbrella and its tasks appear in your task views like any other work — you watch the waves progress, and each task lands as its own pull request for you to merge.

Board review and redraft

Sending a batch for Board review & Start doesn't end your intake chat the way it might feel like it should — the chat stays open, parked against the umbrella, while the Product Owner and Head of Marketing review it. When they finish, their feedback comes back into that same still-live chat as one brief: every root-subtask's current title, description, and acceptance criteria, alongside the board's decision notes and an instruction to re-propose the whole batch in a single call. You can go back and forth with the intake agent from there, and confirming the revised batch updates the existing umbrella and root-subtasks in place rather than starting over — items whose project scope didn't move are patched positionally; only an item whose scope actually changed gets cancelled and recreated. The board can review again for another round if you want one.

The same redraft path works after the fact, too. Task Detail's Re-draft with board feedback button — normally a per-task control — also handles a MegaTask's branchless umbrella: it recovers the batch's multi-repo scope from the live root-subtasks instead of needing a project to redraft against, so redrafting a MegaTask from its umbrella works exactly like redrafting a single task.

llms.txt