Organizing work

Once you have more than ~20 tasks in a project, raw columns aren't enough. Meshly Build gives you three orthogonal grouping tools — milestones, epics, and labels. Each does one thing well; together they cover every way teams want to slice their work.

TL;DR

A task can be in milestone "Version 3.0", under epic "Onboarding redesign", with labels frontend + ui/ux. The three don't conflict; they answer different questions.

Milestones (a.k.a. sprints / releases)

A milestone is a time-bound bucket of work. Examples:

• Version 3.0
• Q3 — Customer onboarding
• October bug bash

Each project can have one active milestone at a time. The active milestone is what agents prefer when picking up Backlog work (the agent rules say "always prioritize tasks from the active milestone"), and it's what the dashboard summary highlights.

Create milestones in Settings → Project → Milestones. Mark a milestone active to make it the default for newly-created tasks.

When a milestone is finished, close it (don't delete) — closed milestones drop out of the filter dropdown by default but stay searchable.

Epics

An epic is a thematic grouping that may span multiple milestones. Examples:

• Onboarding redesign — could span V3.0 and V3.1
• License management — was V3.0 only
• Auto-reviewer agent — currently V3.1

Use epics when:

• A feature is bigger than a single release
• You want to filter the board by "everything related to X" regardless of when it ships
• You want a single Done-or-not status across many tasks

One task → at most one epic. Create epics in Settings → Project → Epics.

Labels

Labels are free-form tags. Use them for anything that isn't naturally a milestone or epic:

• Type of work: bug, feature, chore, docs, refactor
• Area: frontend, backend, devops, infra, ui/ux
• Risk / class: security, breaking-change, planning
• Process: needs-design, customer-reported, tech-debt

A task can have any number of labels. Labels are project-scoped — same name in different projects is fine but they're distinct labels.

Default labels are seeded on first run; add your own in Settings → Project → Labels.

Filtering the board

The board's filter toolbar lets you combine all three:

• Milestone selector (multi-select; supports None for unscoped tasks)
• Epic selector (multi-select; supports None)
• Priority selector
• Assignee selector
• Label selector (multi-select; ANDs across labels — task must have all selected)
• Search box (matches title, description, and task ID)

The combined filter is preserved per-project in your browser. If you set a default saved view, that's what loads each time you open the project. Filters are scoped per project — switching to a different project won't carry filters across.

Grouping (swimlanes)

Beyond filtering, you can group columns by a dimension. Open the toolbar's Group by dropdown:

• None — flat columns (default)
• Milestone — tasks bucket into horizontal swimlanes by milestone
• Epic — same, by epic
• Assignee — by who's working on what
• Priority — by criticality

Grouping is useful for "show me all the V3.1 backend work, grouped by epic, ranked by priority" type views.

Conventions worth adopting

• Active milestone reflects current shipping work. Don't let multiple milestones drift to "open" simultaneously. Close finished ones promptly.
• Use epics sparingly. One per ongoing initiative, not one per task batch. If you have 20 epics in a project, you're using them as labels — switch to labels.
• Label vocabulary should be small and shared. Aim for ~10-15 labels per project, not 50. A bug label that means different things across two teammates is worse than no label.
• Don't tag everything planning. That label means "this is a design doc, not implementation". Implementation tasks shouldn't have it.

What's next

• Working with tasks — task lifecycle in detail
• Agents and API keys — manage who can claim work