| name | tma1-peer |
| description | Pull recent session content from peer coding agents (Claude Code, OpenClaw, Copilot CLI) that worked on the same project. Invoke this skill when the user asks you to read another agent's review feedback, see what someone else tried, or act on cross-agent context. Trigger phrases: "what did claude do", "what did openclaw do", "what did copilot do", "peer sessions", "cross-agent context", "/tma1-peer". |
TMA1 Peer-Agent Lens (Codex)
You're being invoked because the user wants to see what a peer coding agent
left on this project — typically because they used Claude Code, OpenClaw,
or Copilot CLI to review or run something and now want you to act on that
work without copy-pasting it manually.
How to invoke this skill
This skill is auto-selected when the user mentions reading another agent's
output on the current project, or when they explicitly type
/tma1-peer [agent] [count] [messages]. Parse:
- First positional arg (optional): peer agent name (
claude / claude_code
/ openclaw / copilot / copilot_cli / all). If this arg is a bare
integer (e.g. /tma1-peer 3), there's no agent token: it is the count, and
the next integer (if any) is messages per session — use agent_source: ""
(all peers). Do not reject it as an unknown agent. E.g. /tma1-peer 3 30 →
count 3, 30 messages.
- Count (first integer, after the agent name when present): recent sessions to
pull, integer 1-5, default 1.
- Messages per session (the integer after count): integer 1-100, default 10.
If none is supplied, treat as all with count 1 and 10 messages.
Normalize the agent name
| Input | Canonical agent_source to send |
|---|
claude, cc | claude_code |
claude_code | claude_code |
openclaw | openclaw |
copilot | copilot_cli |
copilot_cli | copilot_cli |
all, *, empty | "" (returns all non-Codex peers) |
Any other value: reply
unknown peer agent "<X>"; available: claude, openclaw, copilot, all and
STOP — do not call the tool with an unrecognised name.
Call the tma1 MCP tool
This project's TMA1 install registers an MCP server named tma1. Call
the get_peer_sessions tool on that server with:
| Argument | Value |
|---|
agent_source | the canonical name from the table above (or "") |
limit | the parsed count — when the user gave a count you MUST pass it (don't default to 1); omit only when none was given (server default 1, clamp [1, 5]) |
message_limit | the parsed third arg if supplied (clamp [1, 100]), otherwise 10 |
If your runtime addresses MCP tools by a prefixed name (for example
tma1.get_peer_sessions or mcp_tma1_get_peer_sessions), use whichever
convention this Codex install uses — the tool itself is the same one
backing TMA1's perception layer.
Use the returned content directly
The response is a JSON object with two top-level fields worth knowing
about:
sessions array — each entry has:
- Identity:
session_id, agent_source, started_at,
last_activity_at, last_activity_ago, duration_minutes, cwd.
- Volume:
tool_call_count, tokens_input, tokens_output.
- Content:
messages (chronological user / assistant / thinking),
recent_tool_names, files_touched.
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: ""). Check 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.
When you act on what the peer left:
- Quote concrete points the peer made. Don't paraphrase. The user
uses this skill specifically because they want the peer's exact
feedback in your context, not your summary of it.
- List the files the peer touched. If the user's next step is "fix
what Claude flagged", you need to know which files matter.
- Surface the timing. "Claude left this 12 min ago" is more useful
than "recently".
If sessions is empty AND partial_failures is absent, reply
no recent <agent> sessions on this project in the active window
and stop — do not fabricate context. If partial_failures is present,
quote the failed agent(s) instead of asserting silence.
Examples
User: "what did claude leave on this project?"
You: (call get_peer_sessions with agent_source: "claude_code", limit: 1, message_limit: 10)
You: "Claude Code reviewed server/internal/handler/anomalies.go 8 minutes ago and flagged three concrete issues:
- fetchEmits has no LIMIT — body cap will truncate before the query finishes.
applyForceColor env dedup is libc-dependent.- anomalyCache.history map never evicts stale sessions.
Want me to address all three or pick one?"
User: /tma1-peer copilot 2
You: (call get_peer_sessions with agent_source: "copilot_cli", limit: 2, message_limit: 10)
You: "Copilot CLI ran two sessions on this project today — the most recent
deployed staging 20 min ago (success), the prior one 2 h ago ran the
test suite and hit a flake in TestSemAcceptsUpToCapacity."
