Briefs (AM/PM Context Recovery)

Starting a work session is the hardest part. What were you working on? What’s blocked? What should you tackle next? Monday Morning’s briefs answer these questions automatically by reading your project’s current state and producing a focused summary.

What briefs are

A brief is a generated summary of your project’s current state. There are two kinds:

Brief	When to use	What it covers
AM brief	Start of day / returning to a project	Recent activity, current blockers, suggested next steps
PM brief	End of day / stepping away	What was accomplished, what’s still open, handoff notes

Briefs are not stored as permanent files — they’re generated on demand from the live state of your .mm/ folder. Every brief is fresh.

The /mm:am command

Run this when you sit down to work:

/mm:am

The AM brief reads your project and produces:

• Recent changes — specs and tasks that were updated since your last session, based on file modification times
• In-progress work — tasks currently in ## In Progress across all specs
• Blockers — issues marked as open, especially those tagged [CRITICAL] or [BLOCKER]
• Suggested next steps — the highest-priority pending work based on spec status and task ordering
• Stale specs — specs with ## In Progress tasks that haven’t been touched recently

The goal is to get you productive in under a minute. Instead of opening multiple files and piecing together state, you get a single coherent picture.

The /mm:pm command

Run this when you’re wrapping up:

/mm:pm

The PM brief captures:

• What was accomplished — tasks completed today, based on file changes
• What’s still open — in-progress tasks and their current state
• New issues — any issues created during the session
• Tomorrow’s priorities — suggested starting points for the next session

This is especially useful when you’re working across multiple projects. The PM brief gives your future self (or a teammate) a clean handoff without having to write a manual status update.

How briefs help with context switching

Modern development often means jumping between projects, repositories, or client work. Each switch has a cost — the time it takes to remember where you left off. Briefs reduce that cost by:

1. Reading project state, not your memory — the brief is generated from files, not from what you remember
2. Surfacing what changed — you see what moved since you last looked, not the entire project
3. Prioritizing next actions — instead of scanning a backlog, you get a ranked list based on current state

If you context-switch between two projects during a day, running /mm:am on the second project when you return to it is the fastest way to re-orient.

What briefs don’t do

Briefs are read-only summaries. They don’t modify any files, create tasks, or change issue states. They’re a view into your project, not an action on it.

If a brief surfaces something that needs attention — a stale spec, a critical blocker, an overdue task — you take action separately using the appropriate command (/mm:spec-start, /mm:issue, etc.).

Team alignment

When multiple people work on a project (each with their own Claude Code sessions), AM briefs give everyone the same starting picture. Because briefs are generated from the shared .mm/ folder, two people running /mm:am at the same time see the same state.

This doesn’t replace standups or communication — but it means everyone starts from the same factual baseline.

Related

• Specs & Workflow — the spec lifecycle that briefs summarize
• Tasks & Progress — how task status feeds into brief generation