tma1-peer git:20260621.1b02338A

Immutable. This exact content never changes and is served at /api/v1/blob/38e4cf7779bfde96.

---
name: tma1-peer
description: "Pull recent session content from peer coding agents (Codex, OpenClaw, Copilot CLI) that worked on the same project. Invoke when the user wants you to read another agent's review feedback, see what someone else tried, or act on cross-agent context. Trigger phrases: \"what did codex do\", \"what did openclaw do\", \"what did copilot do\", \"peer sessions\", \"cross-agent context\", \"/tma1-peer\"."
argument-hint: "[agent] [count] [messages]"
allowed-tools: ["mcp__tma1__get_peer_sessions"]
---

# TMA1 Peer-Agent Lens

You're being invoked because the user wants to see what a peer coding agent
left on this project — typically because they used another agent to review
or run something and now want you to act on that work without
copy-pasting it manually.

## Syntax

```
/tma1-peer                 # all peers, latest 1 session each, 10 messages
/tma1-peer codex           # codex, latest 1 session
/tma1-peer codex 3         # codex, latest 3 sessions
/tma1-peer codex 3 30      # codex, latest 3 sessions, 30 messages each
/tma1-peer openclaw        # openclaw, latest 1
/tma1-peer copilot 2       # copilot_cli (alias), latest 2
/tma1-peer all 2           # all peers, 2 each
```

## How to handle the invocation

1. **Parse the user's arguments** after `/tma1-peer`:
   - First token (optional): agent name.
   - **If the first token is a bare integer** (e.g. `/tma1-peer 3`), it is the
     count, not an agent — use `agent_source: ""` (all peers) and that integer
     as the count. Do NOT reject it as an unknown agent.
   - Second token (optional): count (integer 1-5).
   - Third token (optional): messages per session (integer 1-100, default 10).
2. **Normalize the agent name**:
   - `codex` → `codex`
   - `openclaw` → `openclaw`
   - `copilot` or `copilot_cli` → `copilot_cli`
   - `all`, `*`, or empty → `""` (means all peers, excludes Claude Code)
   - a bare integer → treat as count (see step 1), `agent_source: ""`
   - **Anything else** → reply to the user: `unknown peer agent "<X>"; available: codex, openclaw, copilot, all` and STOP — do not call the tool with an unrecognized name.
3. **Call the MCP tool `mcp__tma1__get_peer_sessions`** with:
   - `agent_source`: parsed agent (or empty string)
   - `limit`: the parsed count. **When the user gave a count, you MUST pass it**
     — do not silently fall back to 1. Omit only when no count was supplied
     (server default 1, clamp to [1, 5]). E.g. `codex 3` → `{agent_source: "codex", limit: 3}`.
   - `message_limit`: the parsed third token if supplied (clamp to [1, 100]),
     otherwise `10`. E.g. `codex 3 30` → `{agent_source: "codex", limit: 3, message_limit: 30}`.
4. **Read the returned conversation messages** and use them as direct input
   for your next reasoning step. **Do not paraphrase** — when acting on
   peer feedback, quote the specific points the peer made so the user can
   verify you got it right.

## What the tool returns

A JSON payload with two top-level fields worth knowing about:

- **`sessions`** — array, each entry has:
  - `session_id`, `agent_source`, `started_at`, `last_activity_at`, `last_activity_ago`, `duration_minutes`
  - `tool_call_count`, `tokens_input`, `tokens_output`, `cwd`
  - `messages`: chronological list of user / assistant / thinking messages
  - `recent_tool_names`: top 5 tools the peer agent used
  - `files_touched`: distinct file paths the peer Read / Edited
- **`most_recent_session`** — shortcut to the freshest peer's `agent_source` +
  `last_activity_at` + `last_activity_ago`. Use this for your first-line
  summary so the user instantly knows whether the peer work is current.
- **`partial_failures`** — map of `agent → error_message`. Present **only**
  when one or more per-agent queries failed in the all-peers fan-out
  (`agent_source: ""`). **Read this before treating empty `sessions` as
  "no peer activity"** — a non-empty map means the result is incomplete;
  tell the user which peer(s) couldn't be reached rather than asserting
  silence.

Empty `sessions` with **no** `partial_failures` means no peer activity
found in the time window — tell the user "no recent <agent> sessions on
this project" rather than fabricating context.

## Examples

User: `/tma1-peer codex`
You: (call tool with `agent_source: "codex", limit: 1, message_limit: 10`)
You: "Codex reviewed `auth.go` 12 min ago and left three concrete issues:
     1. ... 2. ... 3. ... Want me to address all three or pick one?"

User: `/tma1-peer`
You: (call tool with `agent_source: "", limit: 1`)
You: "Two peers active recently — Codex (5 min ago, reviewing auth.go) and
     Copilot CLI (20 min ago, deployed staging). Which do you want me
     to dig into?"