---
name: tm
description: trusty-mpm orchestration model overview — agents, skills, delegation
user-invocable: true
version: "1.0.0"
category: pm-reference
tags: [overview, orchestration, framework]
effort: low
---
# /tm — trusty-mpm Overview
trusty-mpm is a Rust daemon + MCP-server platform (not the Python
`claude-mpm` project — see `docs/WHAT-IS-TRUSTY-MPM.md` if that distinction
ever matters). A **PM agent** coordinates specialist agents through
structured delegation; it does not implement, investigate, or verify
directly. See `tm-circuit-breaker` for the full enforcement model behind
that rule.
## How Delegation Works
The PM breaks a request into subtasks and delegates each to the right agent
via the Agent/Task tool. Independent subtasks run in parallel; dependent
ones run sequentially. An agent that needs another specialty reports back to
the PM rather than self-delegating.
**Typical chain**: Research → Engineer → Ops (deploy) → Ops (verify) → QA →
Documentation. See `tm-delegation-patterns` for the concrete chains and
`tm-workflow` for how a project customizes the phase model.
## Agent Roster (Bundled)
**This document does not carry the roster.** Which agents are bundled, which
deploy to a given project, and what condition gates each one are DATA, declared
in the bundled `framework-manifest.toml` — the framework tier of the
`manifest.toml` format. That file is the authority; a prose copy of it here
would drift, and did (#4760: `ops` sat "DEPRECATED" in prose for months while
still reaching every roster). Read it two ways:
- **`tm-capabilities`'s `references/agents.md`** — the manifest rendered as a
table, one row per agent, with its category, its exact deploy condition, and
its declared skills. Mechanically regenerated; never hand-edited.
- **The project's own deployed roster** — what THIS project actually received.
The launch prompt's generated roster section is that answer; use it rather
than assuming any agent is present.
See `tm-agent-architecture` for how agents are built (the `extends:` compose
chain) and how to update one safely, and `tm-delegation-patterns` for which
agent to route a given task to.
## Skills System
Skills are Markdown files at `.claude/skills/<name>/SKILL.md` providing
reusable knowledge/procedures. User-invocable skills respond to `/skill-name`;
others load automatically on context triggers.
**The bundled skill roster is declared in `framework-manifest.toml`, not
here** — same authority, same reason, as the agent roster above. Every declared
skill is `universal`: it deploys to every project. For the list with each
skill's description and whether it is user-invocable, see `tm-capabilities`'s
`references/skills.md`.
## Memory System
`mcp__trusty-memory__*` provides persistent cross-session context —
`memory_recall`/`memory_recall_deep` to read, `memory_remember`/`memory_note`
to write, `task_add`/`task_list`/`task_complete` for durable task tracking.
Not a per-agent file on disk (unlike claude-mpm) — a live MCP-backed memory
palace. Check before research or delegation, per `tm-tool-usage-guide`.
## Health and Diagnostics
```bash
tm doctor # full stack diagnostic (see tm-doctor)
mcp__trusty-mpm__supervisor_status # fleet-level health
mcp__trusty-search__search_health # trusty-search liveness
```
No dashboard on `:8765` — that's claude-mpm's Socket.IO monitor, which does
not exist here. Use the TUI (`tm tui`) or the MCP health tools above.
For the exhaustive, always-current version of the CLI/MCP/agent/skill/doctor
surfaces summarized above — exact command names, tool schemas, and
per-agent/skill descriptions — see the auto-generated `tm-capabilities` skill
(regenerated by `tm generate capabilities`, never hand-edited).
## Available Commands
| `/tm` | This overview |
| `/tm-doctor` | Full diagnostic (`tm doctor`) |
| `/tm-workflow` | Workflow/phase customization |
| `/tm-ticket` | Ticketing orchestration |
| `/tm-session` | Pause/resume session management |
| `/tm-adr` | Architecture Decision Records |
| `/tm-postmortem` | Session-error analysis and reporting |
## Architecture & Design Patterns
**Core design patterns** (memory/sessions/search) are documented in
`docs/ARCHITECTURE-MEMORY-SESSIONS-SEARCH.md`:
- **Memory over MCP** — discovery-based daemon contact, never hardcoded ports
- **Session↔Worktree 1:1 Model** — semantic naming, per-session isolation
- **Per-Worktree Search Index** — automatic index derivation, lifecycle management
Read this if you are building tools that rely on the framework's internals or
debugging production behaviour.
## For Agents: Working Within trusty-mpm
Focus on your delegated task; return results with evidence (file paths,
test counts, commit hashes — see `tm-verification-protocols`). Report back
to the PM if you need another specialty rather than self-delegating.
Escalate blockers immediately rather than silently producing a partial
result.