Roadmap & Automated Setup

Monday Morning helps you go from a product vision to an executable plan. You start by defining your mission and roadmap, then turn that roadmap into the specs you’ll actually implement — sequenced by their dependencies into a build order. The result is a project that’s scaffolded and ready to dispatch agents at, instead of a blank .mm/ directory.

The planning model

Planning flows from broad intent down to individual work items, but the spine is simpler than a classic hierarchy: the spec is the primary unit of work, and specs are sequenced by their dependencies, not by feature membership.

Level	What it is	Where it lives
Product	Mission, target users, tech stack	`.mm/product/`
Roadmap	Phased list of what you’ll build	`.mm/product/roadmap.md`
Specs	Detailed specifications for a unit of work — the primary unit	`.mm/specs/{date-slug}/`
Tasks	Checklist items inside a spec	`spec.md` `## Tasks` section
Features	Optional labels that group related specs	`.mm/features/{slug}/feature.json`

A roadmap item becomes one or more specs; each spec breaks down into tasks; a feature is an optional grouping label for at-a-glance progress — it is never required to create or sequence a spec.

Product planning

Planning documents live in .mm/product/:

mission.md — product vision, target users, and core value
roadmap.md — phased development plan
tech-stack.md — technology choices

These files give Monday Morning (and any agent working in the project) the context to make decisions that fit your product.

Greenfield: start from scratch

For a new project, run /mm:plan. Monday Morning walks you through your product idea, target users, key features, and tech stack, then generates the .mm/product/ files.

Brownfield: backfill from existing code

If you already have a codebase, run /mm:update-product. Instead of asking you to describe everything from scratch, Monday Morning analyzes the existing project — dependencies, file structure, and any README or manifest files — to detect your tech stack and current features, then asks targeted questions to fill in the gaps. The command is additive and won’t overwrite existing product docs.

The roadmap

A roadmap is a phased list of work. Phases group related milestones, and each milestone is a checkbox item:

## Phase 2: 1.0 Launch Ready

> Status: in_progress
> Target: 2026-Q3

- [ ] Pro checkout flow and pricing page
- [x] First-launch onboarding
- [ ] Feature gating across all surfaces

Early phases capture foundational work; later phases capture planned and exploratory work. You can keep the roadmap as detailed or as high-level as you like — it’s the source for the scaffolding step below, and it’s what the desktop app’s roadmap board renders.

Roadmap to features: automated scaffolding

Once the roadmap exists, /mm:roadmap-to-features converts roadmap items into Monday Morning features. For each item it creates a folder and a feature.json file:

.mm/features/{feature-slug}/feature.json

A feature is an optional grouping label — it holds metadata and links to the specs that implement it, so related specs roll up into one progress line. This is the automated scaffolding step: instead of hand-creating a folder per roadmap item, Monday Morning generates them for you in one pass.

The command is non-destructive. If a feature with the same slug already exists, it’s skipped rather than overwritten, so you can re-run it after editing the roadmap to sync new items without disturbing existing ones.

Specs and the build order

The real work happens in specs. Create one with /mm:spec — it captures the goal, requirements, and a task breakdown in the spec folder. From there you implement with /mm:spec-start, or dispatch an agent at it from the desktop app.

Ordering is spec-level. Each spec declares its prerequisites in spec.md frontmatter:

depends_on:
  - 2026-05-01-auth-schema
  - 2026-05-03-session-store

Then /mm:order-specs (or the mm_order_specs MCP tool) reads every incomplete spec’s depends_on, topologically sorts them into numbered waves, and writes a project-wide .mm/specs/order.json — the ordering authority the desktop app reads. Specs in the same wave with no dependencies on each other are marked parallel and can run concurrently.

The full flow:

Product → Roadmap → Specs (+ optional feature labels) → order.json → Implement

In the desktop app, the roadmap board occupant presents this plan as a list — phase bands group rows, and every row carries a dispatch verb, so you can put an agent on a roadmap item directly. See The Floor and The Doors Bar for where the roadmap surfaces.

For everything that happens once a spec exists — the spec lifecycle, the spec folder layout, progress tracking, and wave sequencing in depth — see Specs & Workflow.

Specs & Workflow — the spec lifecycle from planning to verification
The .mm/ Data Model — full reference for the .mm/ directory structure