Subtasks

Most tasks are a single piece of work, and Every keeps them that way. But when one job splits across several people or phases, you can break it into subtasks: the original task becomes a parent that exists only to group them, and each subtask is a full task in its own right, with its own status, due date, priority, assignees, estimate, and time tracking.

How the family fits together

A parent task and its subtasks are one "thing" in Every, and it's the subtasks that people action:

• Subtasks appear everywhere tasks do: boards, lists, personal views, capacity, and reports. They're what your team works on day to day.
• The parent appears almost nowhere. It stays off boards, lists, and capacity, because its numbers are just the sum of its subtasks and would double-count. It does show in search, marked with a Parent badge, since it holds the family's canonical title and description.
• References follow the parent. If the parent is WM-1, its subtasks are WM-1.1, WM-1.2, and so on. The dotted references work everywhere ordinary ones do: search, links in comments, git branch names, and AI assistants.

Creating a family

Two ways in:

• At creation: choose Break into subtasks as the estimate mode when creating a task. The form slims down to what the parent actually keeps (title, description, client and project, owners), and after creating you land on the parent ready to add the subtasks.
• From an existing task: open the ⋯ menu and choose Break into subtasks. The task keeps its reference and becomes the parent, while its current status, assignees, estimate, and logged time all move onto an auto-created first subtask (you choose its title). Comments, attachments, and history stay on the parent as family record.

Add more subtasks any time from the parent's Subtasks panel or the family bar on any subtask. Each new subtask gets the next number; numbers are never reused, even after deleting one.

The parent's page

Opening a parent shows the family overview: the shared description, a Subtasks table (reference, job number, title, status, assignees, and progress with a logged-versus-estimate bar), and a quick-add box. Rows support the full right-click menu, so you can retitle, reassign, or move a subtask's status without leaving the page.

The parent has no status, assignees, or estimate of its own. Instead its sidebar shows a Calculated Estimate, always the sum of its subtasks' estimates, and Time Tracked totalled across the family. Time can't be logged on the parent itself.

Working in a subtask

A subtask opens as a normal task page with a family bar across the top: the parent's reference and title (linking to the overview), and a pill for every sibling showing its number, title, and status, with the one you're viewing highlighted. Switching between siblings happens there, and a + on the bar adds another.

Some fields are managed at the family level and locked on subtasks:

• Client and project always match the parent; moving the parent moves the whole family (and renumbers it together, with old links redirecting).
• Job number is inherited from the parent, and changing the parent's updates every subtask. A subtask can still set its own, until the parent's next change overwrites it.
• Owners are the parent's owners, mirrored to every subtask.

Descriptions are shared by default: a subtask without its own description shows the parent's, labelled as shared. Write into it to override for that subtask alone, and revert to the shared text any time.

Everything else is per-subtask, including the retainer: each subtask chooses its own (or falls back to the project's), the parent holds none, and one family can bill across several retainers. The full estimate workflow is per-subtask too: request an estimate from a subtask's assignee and it goes through the same submit-and-approve loop as any task, rolling up into the parent's calculated estimate once set.

Archiving

Archiving the parent archives the whole family. Individual subtasks can be archived on their own, and the parent's calculated estimate adjusts.

For integrations

Subtasks are first-class in the REST API and MCP server: dotted references resolve everywhere, task responses include is_parent, parent, and subtasks fields, POST /api/v1/tasks accepts a parent_task_id, and a convert endpoint and matching MCP tools (create-subtask, convert-task-to-parent) cover the rest.