Planning a spec

Before any Worker runs, the Queen plans. Her first move is the decomposition pass: she reads your natural-language spec and produces a dependency-ordered task graph — a set of concrete tasks plus the edges that say which task must finish before another can start.

What the decomposition pass does

You submit a spec

From your Hive you write what you want in plain language. The spec is the contract: the clearer the intent and the acceptance criteria, the better the plan.

The Queen assembles context

The Queen does not plan in a vacuum. She combines your spec with a compact view of the Hive: a summary drawn from SwarmMemory, the top of your repo file tree, recent commits, and which Workers are available.

She decomposes into a task graph

Using that context she produces a dependency-ordered graph — independent tasks that can run in parallel, and dependent tasks ordered behind the work they rely on.

She validates the graph

The graph is checked for structural soundness before execution: no cycles, every dependency resolvable, each task scoped to something a Worker can act on.

What a good spec looks like

A spec the Queen can plan well reads like a brief, not a wish:


Goal: Add password reset to the auth flow.
Acceptance criteria:
  - "Forgot password" link on the login screen
  - Email with a one-time, time-limited reset token
  - New-password form validates strength and confirms match
  - Old sessions invalidated after a successful reset
Constraints: reuse the existing email adapter; no new dependencies.

Clear acceptance criteria give the Queen testable boundaries for each task, and they give the Drones something concrete to review against later.

SwarmMemory shapes the plan. A Hive with well-maintained memory — architecture notes, prior decisions, conventions — yields tighter, more accurate task graphs than a cold one. Investing in your knowledge graph pays off at planning time.