The four team tools (tool/team_tools.ts) on the rules of team/team.ts,
driven from real turns by team/runtime.ts:
- Members run on the subagent job machinery (app.ts spawn with `member`):
background, unattended, their own prompt from blocks/team_member.md
(the whole of team_lead.md for one with lead: true), team_send and
team_read (team_add and team_stop for one that leads). Not jobs to the
model: job_list and the job_* tools skip them; a client over the link
still sees them as subagent jobs named "<name>: <role>".
- The room: messages and reports with their marks, delivered at the next
step boundary or waking a finished member or the idle lead; report
posts to the manager.
- A manager's work calls answer the refusal before the permission check,
by risk class (an MCP tool by its readOnlyHint); the tool list is
unchanged. job_stop and reading bash stay.
- Slots: the lead waits for one before its turn (Esc stops the wait);
members wait in order; task helpers in a team count toward the size
and hold a slot; job_send restarting a helper is refused when full.
- The offer is decided with the prompt and kept with it: a resumed
session takes it from its kept tool list.
- The size: agents.min/max settings, refused outside 1 <= min <= max <=
cap, kept across /new and resume; said in a note on the first message,
after a change, after a compaction and a rewind.
- TUI: /team (tree and room, size, stop a member, dialogs for both), an
"agents" row beside the effort in /effort, "team n/max" in the status
bar. /team works over ACP too.
tests/team.test.ts runs a lead, a member and its report through the app.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The system prompt is made once per session (start, compaction, model
switch), kept in session_meta and resent byte for byte; it holds no
date. What changes mid-session -- the date, a mode the person chose, a
plan or memory or instruction file they edited, a personality, MCP
instructions that arrived later -- is a <session-note> on the next user
message, stored with it. The tool list is fixed for the session:
plan_submit is always offered and answers unavailable outside plan
mode, the wrap-up keeps the tools and runs no call, a withdrawn tool
stays listed and answers its refusal; the first request waits up to
mcp_wait_ms for MCP servers. Compaction asks for its summary as the
next turn of the same conversation. Cached input tokens are parsed
(incl. llama.cpp timings), stored per request and shown in /context.
Spec: context.md §7/§10, loop.json context.note (+ plan_ended,
plan_own, personal, empty, mcp_wait_ms), modes.json plan.refused,
compact.md without the transcript heading. Conformance area prefix.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
HomerandClaude Opus 5.5