Recursive tasks

Some goals cannot be fully enumerated upfront. A project onboarding guide needs verified features and entry points before its chapters can be planned, written, checked, and combined. Recursive tasks support work that must be refined in stages.

If you already know that two files need independent reviews, ordinary swarm is usually sufficient. Recursive mode is not simply a way to increase concurrency.

Define the deliverable first

Give one complete goal, its inputs, boundaries, and acceptance criteria:

Create an onboarding guide from the current project. Verify installation, actual entry points, and required configuration before organizing chapters, writing instructions, and checking links. Edit only docs/guide. Include the expected result of every step. List unsupported claims as unresolved and do not publish the site. Deliver the guide, verification results, and outstanding questions.

This defines what to deliver, where changes are allowed, and how to judge completion without prescribing a fixed number of steps or agents.

Enable recursive tasks

In a supported coding session, enable Continuous swarm, then Recursive tasks, and send the complete goal. If unavailable, follow the runtime support indication. The ordinary swarm toggle does not enable recursive mode.

Unlike line-by-line continuous tasks, submit a coherent goal whose internal hierarchy can be organized by the runtime.

Understand the hierarchy

An onboarding guide might be organized as follows. This is an example, not a fixed role template:

Chapters depend on verified facts but may not depend on each other. Recursive execution refines tasks and dependencies as needed; it does not allow every node to create unlimited branches.

Follow execution

Identify completed, running, and dependency-blocked work. One failed prerequisite may prevent several downstream tasks from starting; it does not mean each downstream task failed during execution.

Check whether completed output supports the next stage. A finished outline does not make the guide ready for delivery while installation facts remain unresolved.

Where budgets and usage are displayed, distinguish permitted capacity from observed consumption. The tree has depth, size, and time constraints. When a limit is reached, examine what was actually covered rather than assuming that a returned result fulfills the entire goal.

Continue after interruption

Supporting runtimes provide snapshots and an Inspect and resume action. Read the current state, check completed artifacts and pending nodes, and identify file or external operations that may already have happened before requesting recovery.

If chapters were written but link checking was interrupted, verify that the chapter files remain intact before completing the checks. A missing final summary is not a reason to regenerate every chapter.

Recovery support depends on the runtime. Without reliable execution state, inventory existing results and issue a clearly scoped follow-up task. See Recovery and follow-up.

Accept the whole result

Return to the original request: can someone follow the guide, does every step state its expected result, do links work, and are uncertainties explicit?

Completing individual branches only establishes that those branches produced output. The final guide still needs duplicate sections, inconsistent terminology, and contradictions resolved. Publishing or deploying requires the corresponding authorization; recursive mode does not grant it.