Tasks & Progress

Tasks are the atomic units of work in Monday Morning. They live in two places: inside a spec’s spec.md, under its ## Tasks section (most common), or as standalone quick task files in .mm/tasks/ for one-off work that doesn’t belong to a spec.

Tasks within specs

Every spec tracks its tasks in spec.md’s ## Tasks section, under four sub-headers:

## Tasks

#### Completed
- [x] T1: Database schema migration (R1)

#### In Progress
- [ ] T2: Build API endpoints (R2)
  - [ ] T2-1: GET /users endpoint
  - [ ] T2-2: POST /users endpoint

#### Blocked

#### Backlog
- [ ] T3: Write integration tests (R2)
- [ ] T4: Update API documentation (R3)

Tasks use standard markdown checkboxes. When a task is finished, it moves under #### Completed with - [x]. Subtasks (indented checkboxes) let you break larger tasks into steps, and the trailing (R1) cites the requirement id the task satisfies — /mm:verify-spec uses those ids to check coverage.

Legacy specs created before tasks moved into spec.md use a separate implementation.md with ## -level headers instead. Tools fall back to it automatically for those specs; never create it for a new spec.

Section headers

The parser recognizes exactly these sub-sections inside ## Tasks:

Section	Meaning
#### Completed	Finished tasks
#### In Progress	Tasks being actively worked on
#### Blocked	Tasks waiting on something
#### Backlog	Tasks planned but not started

Use #### (four hashes). Three hashes (### ) will not be recognized by the progress tracker.

Creating and completing tasks

Prefer the universal MCP verbs over hand-editing:

1. mm_create with entity: "task" — writes tasks into the spec’s ## Tasks section. It accepts a batch of titles, so a whole task list lands in one write.
2. mm_complete with entity: "task" — marks a task done, checks whether the spec’s tasks are all complete, and triggers progress rollup (including refreshing the spec index that powers prior-work retrieval).
3. Edit the file directly — change - [ ] to - [x] and move the line under #### Completed. Fine for humans; agents should use the tools.

The tool-based path is what agents use during /mm:spec-start — it keeps the file format correct and the rollup consistent.

Standalone quick tasks

Not everything belongs in a spec. Quick fixes, maintenance chores, and one-off items go in .mm/tasks/ as individual markdown files:

.mm/tasks/
├── tasks.md                          # Dashboard (auto-maintained)
├── fix-login-redirect-05-12-2026.md  # Individual task file
└── update-deps-05-10-2026.md         # Another task file

Each quick task file carries frontmatter:

---
title: Fix Login Redirect
type: quick
status: building
priority: high
created: 2026-05-12T10:00:00Z
updated: 2026-05-12T10:00:00Z
---

# Fix Login Redirect

• type: quick marks it as a quick task.
• status is one of parked, building, in-review, done.
• priority is high, medium, or low.

Important: each standalone task must be its own file. Don’t just add a line to tasks.md — the dashboard file is a summary view, not the source of truth. Complete a quick task with mm_complete using entity: "quick".

Quick tasks are deliberately a side channel: the desktop app’s surfaces center on specs, and standalone tasks no longer get their own navigation. The spec is the primary unit of work; reach for a quick task only when spinning up a spec would be overkill.

Progress tracking

Monday Morning calculates progress at three levels:

Level	How it’s calculated
Task	Binary — - [x] is done, - [ ] is not
Spec	Percentage of [x] tasks out of total tasks in the ## Tasks section
Feature	Percentage of completed specs out of total linked specs (features are optional labels)

Task and feature rollups are immediate. Spec doneness is stricter: checking off the last task puts a spec in review, and it only reads as done after a passing /mm:verify-spec verdict or an explicit human override. See Specs & Workflow for the full done semantics.

What you see in the desktop app

There is no kanban board. Progress surfaces where the work does: the roadmap board occupant lists specs with their state, the entity detail view shows a spec’s full task list, and the Roadmap door in the doors bar carries the project’s “open · total” count at a glance.

Time estimates

You can optionally add time estimates to tasks:

- [ ] T3: Write integration tests (2h)
- [ ] T4: Update API documentation (30m)

Estimates are informational — they don’t affect progress calculations but can help with planning.

Related

• Specs & Workflow — how specs organize tasks into a structured lifecycle
• The .mm/ Data Model — where tasks live in the file system