Skip to main content

From Request to Deliverable: The Marg Manual

Check what's running

What you'll get

A single report across every team you have put to work: what finished, what is still moving, and what is stuck waiting on something. It takes seconds and reads from a task log Marg keeps on its own, so there is nothing for you to update before you ask.

The steps

1. Ask.

/marg:status

2. Read it by team. Work is grouped under the team running it, completed items first, then in-progress, then blocked. Each blocked item names what it is waiting for, which is almost always one of two things: your approval, or a tool that was unreachable when the work needed it.

3. Act on the last lines. The report closes with the current evidence quality and the next actions worth taking, so the natural rhythm is to read the status, then do the thing it points you at.

What comes back

A snapshot, not a live dashboard, true to the task log at the second you asked. Behind that snapshot sits an append-only history where every status change is a new row rather than an edit. Nothing is ever quietly overwritten, which means the same log that answers "what is running" also answers "what happened, and when."

Variations

  • Fresh workspace: on a new setup with no work yet, status reports "no active tasks found" and points you to onboarding. That is the expected first answer, not a fault.
  • Start-of-day habit: ten seconds on /marg:status each morning surfaces whatever stalled overnight, which is a better time to learn it than mid-afternoon.

If something goes wrong

  • A task you remember is missing: its session may have ended before the log was written. Describe the work in a fresh request, and for a properly interrupted session, chapter 7 is the real recovery path.
  • Something sits in-progress far too long: ask about it directly ("what happened with the pricing analysis?"). If its session was cut off, /marg:resume picks the work back up.
  • The report contradicts what you were handed: trust the deliverable you have, then flag the mismatch so the log gets a superseding row. Because the history only ever appends, a correction adds truth rather than erasing it.