tma1-peer

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:

1. fetchEmits has no LIMIT — body cap will truncate before the query finishes.
2. applyForceColor env dedup is libc-dependent.
3. 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."