Tasks, epics & projects

Structure is the unglamorous half of shipping, with agents or with anyone. A prompt describes an outcome; a backlog encodes a plan: sequencing, sizing, and the boundaries between pieces of work. Masaro gives ideas that shape by default.

Tasks

The unit of hand-off. A task carries a title, description, acceptance criteria, priority (urgent → none), complexity, labels, comments, and its relationships to other work. Everything an agent needs travels on the task; that’s what makes it agent-ready rather than a to-do with ambitions. Tasks can nest: a task may carry subtasks when the work splits but the contract doesn’t.

Epics

Epics group tasks toward one outcome: “passwordless auth,” “usage metering.” They’re how you see the forest: progress across an epic, what’s blocked inside it, what’s left. Tasks don’t have to belong to an epic; unsorted work is fine.

Projects

Projects are the bigger container: a product area or long-running initiative, like “the mobile app” or “billing.” The practical difference from an epic: an epic finishes, a project persists. “Passwordless auth” ships and the epic closes; the mobile app keeps accumulating work forever. Epics live inside a project; project memory (stack, conventions, decisions) attaches at the project level, so everything in a project shares the same house rules.

None of this walls anything off. Tasks belong to the workspace; a project, like an epic, is something a task has, not a place it’s locked inside. The board, task IDs, and search stay workspace-wide. Solo on one product? You may never need a second project, and that’s fine.

Dependencies

Tasks can block other tasks (plus relates to and duplicate of for bookkeeping). Dependencies aren’t documentation; they’re operational. An agent asking for work gets tasks whose blockers are cleared. When a task completes, Masaro tells the completing agent which tasks just became unblocked. Sequencing lives in the graph, not in your head at 11pm.

Complexity

Every task can carry a size: trivial, small, medium, large, xl. Two honest uses:

  1. Scoping discipline. An xl task is usually a plan pretending to be a task. Break it down. Agents do their best work on well-bounded pieces.
  2. Signal for the loop. Complexity tells agents (and you) how long work should plausibly take before something’s wrong.

Where structure comes from

You can build all of this by hand on the board. But mostly you won’t: Brainstorm drafts epics, tasks, dependencies, and complexity from a conversation, and you edit rather than author. The structure is the deliverable; the typing is Masaro’s job.

Good decomposition heuristic: if you can’t write one acceptance criterion covering a task, it’s two tasks.

Next: Brainstorm · The board