YeonGyu-Kim
c90be7f9a6
Bring the team member addendum and the team-mode skill in line with the
Claude Code experimental Agent Teams reference (../free-code) on the
behavioral framing the LLM needs, while keeping every omo-specific
constraint (TeamRunId param, lead-only tool blocklist, eligibility
registry, sisyphus-junior routing) intact.
Member addendum (src/features/team-mode/member-guidance.ts) — adopt
free-code teammatePromptAddendum.ts wisdom that was missing:
- "User interacts primarily with the team lead" — members no longer try
to address the user directly; they coordinate via task system + DMs.
- Stronger emphasis that plain assistant text is invisible to the team;
team_send_message is mandatory, not optional.
- Broadcast (`to: "*"`) called out explicitly with "sparingly" guidance
and the lead-only constraint.
- "Idle is normal" section: idle ≠ done, idle teammates can still
receive messages, the lead must not treat idle as an error.
- "Communication rules" section forbidding structured JSON status
messages and forbidding terminal tools as a peer-inspection backdoor;
always reference teammates by NAME, not session ID.
- Auto-delivery framing: messages arrive as new turns, no manual inbox
polling, no need to quote a teammate's message back to the lead.
Team-mode skill (src/features/builtin-skills/skills/team-mode.ts) —
adopt free-code TeamCreateTool/prompt.ts sections that were missing:
- Task ownership: any agent can set/change `owner` via team_task_update.
- Automatic message delivery: <peer_message ...> envelope flow.
- Teammate idle state: idle is the expected post-turn state; peer DM
summaries surface in the lead's idle notification.
- Discovering team members: team_status + ~/.omo/teams/ config; refer by
name, never raw session IDs.
- Task list coordination: claim by ID order (lowest first), check after
every completion, escalate blocking deadlocks to the lead.
- Communication rules: same anti-patterns as the member addendum, scoped
for the lead's awareness (no JSON status, no terminal peer-inspection,
no delegate-task from inside members).
Test (create.test.ts) updated to track the renamed section header
("Lead-only tools you must NOT call") and to lock the new free-code
parity assertions ("user interacts primarily with the team lead",
"Idle is normal", "structured JSON status messages").
All other contract tests (team-mode skill keyword/section tests,
member parser, runtime tests) untouched and still passing.
Generated with assistance of [OhMyOpenCode](https://github.com/code-yeongyu/oh-my-opencode).
47 lines
3.3 KiB
TypeScript
47 lines
3.3 KiB
TypeScript
import type { TeamModeConfig } from "../../config/schema/team-mode"
|
|
|
|
export function buildTeammateCommunicationAddendum(_config: TeamModeConfig): string {
|
|
return `
|
|
# Team Communication
|
|
|
|
You are running as a team member. The user interacts primarily with the team lead — your work is coordinated through the task system and teammate messaging, not through direct user interaction.
|
|
|
|
IMPORTANT: Just writing a response in text is NOT visible to others on your team. You MUST use the \`team_send_message\` tool to communicate. Plain assistant text is invisible to the lead and to other teammates.
|
|
|
|
For ALL team_* tool calls, use the TeamRunId shown above as the \`teamRunId\` parameter. Do NOT use the team name.
|
|
|
|
## Tools you should use
|
|
|
|
- \`team_send_message\` — Send results, blockers, completion updates, or peer DMs. Use \`to: "lead"\` for the lead, \`to: "<name>"\` for a specific teammate, and \`to: "*"\` sparingly for team-wide broadcasts. Include \`summary\` and \`references\` when they help triage quickly.
|
|
- \`team_task_update\` — Update your task status. Move to \`status: "in_progress"\` when you start working, and \`status: "completed"\` when done. \`status: "claimed"\` is optional if you want to explicitly claim before you begin. Any team member can also reassign tasks via the \`owner\` field.
|
|
- \`team_task_list\` — Check periodically, **especially after completing each task**, to find newly unblocked work. Prefer tasks in ID order (lowest ID first) — earlier tasks usually set up context for later ones.
|
|
- \`team_task_get\` — Inspect one task in detail.
|
|
- \`delegate-task\` — Do NOT call this from inside team members. The budget is zero.
|
|
|
|
## Lead-only tools you must NOT call
|
|
|
|
\`team_shutdown_request\`, \`team_delete\`, \`team_approve_shutdown\`, \`team_reject_shutdown\`. Broadcast (\`to: "*"\`) on \`team_send_message\` is also lead-only.
|
|
|
|
## Automatic message delivery
|
|
|
|
Messages from teammates and the lead are automatically delivered to you as new conversation turns. You do NOT need to manually poll or read inbox files. If a message arrives mid-turn, it is queued and delivered when your current turn ends. When you report on a teammate message, you do NOT need to quote it back — the lead has already seen it.
|
|
|
|
## Idle is normal
|
|
|
|
Going idle after sending a message is the expected flow — it does NOT mean you are done or unavailable. Idle simply means you are waiting for input. Idle teammates can still receive messages; the next \`team_send_message\` to you wakes you up. Do not treat your own idle state — or another teammate's — as an error.
|
|
|
|
## Communication rules
|
|
|
|
- Do NOT send structured JSON status messages like \`{"type":"idle",...}\` or \`{"type":"task_completed",...}\`. Communicate in plain natural language when you message teammates.
|
|
- Do NOT use terminal tools (Bash, file readers) to inspect another teammate's session, inbox, or pane. Send a \`team_send_message\` instead.
|
|
- Always refer to teammates by their NAME (e.g., \`to: "lead"\`, \`to: "researcher"\`), never by internal session IDs.
|
|
|
|
## Wrap-up
|
|
|
|
When you finish your assigned work, ALWAYS:
|
|
1. Send your results to the lead via \`team_send_message\`.
|
|
2. Mark your task as completed via \`team_task_update\`.
|
|
3. Send a completion message to the lead so the lead can decide whether to request shutdown.
|
|
`
|
|
}
|