Team Collaboration

When more than one person works on the same project, the hard part isn’t writing code — it’s staying aligned. Who’s working on what? Did someone already start the spec you were about to pick up? Monday Morning’s team features answer those questions by sharing lightweight status metadata between members, without moving your code anywhere.

Account-optional, cloud lane by default

Monday Morning works fully signed out — signed out simply means “local only, team sharing off.” Signing in enables the cloud lane: team visibility for your .mm/ artifacts, which is the standard sharing mechanism. (A legacy git-mirror sharing toggle exists in Settings → Git sharing, default off; the cloud lane is the supported path.) .mm/ stays gitignored by default — sharing is a settings decision, not a commit.

The team dashboard

The team dashboard is a stage occupant in the desktop app with two regions:

Region	What it shows
Activity	A grouped event feed with relative timestamps and spec deep links — claims, work events, and other team activity, newest first
Projects	The list of projects shared with the team

A few honest notes on how it behaves:

Presence is neutral-only. You can see who’s present; there is deliberately no “what they’re doing” column, and the presence row renders nothing when nobody’s there.
Refresh is a click. The toolbar has a project-scope filter, a refresh control, and a last-updated stamp — never a background poll surfaced as false liveness.
Check-ins don’t feed the feed. Check-ins and activity events live in separate stores with no bridge; the Activity region intentionally does not include check-ins today.
The empty state is a door in. If you’re not on a team yet, the dashboard shows an inline join-team affordance — not an error, not a modal.

Clicking a member’s name deep-links into the artifact browser scoped to their artifacts. The title bar carries a team cell (an avatar stack) with a team menu for switching teams.

Spec claims

Claims solve the “we both built the same thing” problem. When you start work on a spec, you claim it so teammates know it’s taken.

mm_claim_spec — claim a spec. Claims are first-claim-wins, recorded centrally so there’s a single source of truth for who owns what.
mm_fetch_claims — list the current claims for your team.

Both are core tools, listed by default.

The collision radar

mm_team_radar (also core) is the pre-flight check: before starting a spec or branch, it reports whether a teammate is already on it — active work locks, recent working-on and claimed events, and open PRs or recent commits touching the same area. It returns an advisory report and never blocks; call it at the start of a spec or task.

Check-ins

Check-ins are a pushed status snapshot — what you’re working on, your current branch, and a free-text note.

/mm:checkin pushes your status; /mm:team-status views everyone’s.
The underlying tools — mm_push_team_checkin, mm_fetch_team_checkins, and mm_team_refresh — live in the opt-in team tool group (set MM_TOOL_GROUPS=team to list them; they’re always dispatchable by name).

Team settings and seats

Settings → Team is where the team lifecycle lives: create a team, join via an invite code, regenerate the code, remove members, or leave. These operations are backed by row-level security, so each action is scoped to teams you actually belong to. Seat limits are tracked per team.

Local-first by design

Team collaboration is deliberately thin on what it shares. Your code and specs stay in each member’s own repository. What flows through the team backend is lightweight metadata — claims, check-in snapshots, activity events, and which projects are shared. The dashboard is a shared view of status, not a shared copy of your files.

Recap & Briefs — daily briefs that give every member the same starting picture
Specs & Workflow — the spec lifecycle that claims and check-ins reference
The Floor — where the team dashboard and title-bar team cell live