agents-team

This Skill enables general agents team mode. It is disabled by default and only becomes available after you load this Skill.

Principles

• Only use multi-agent tools when the user explicitly requests team mode, or after this Skill is loaded.
• Always explicitly declare roles by using agent_type:
  • orchestrator: plan, delegate, and merge.
  • worker: implement a bounded code or execution task.
  • reviewer: do a read-only audit for bugs, regressions, or missing checks.
  • research: summarize sources / produce supporting material.
  • writer: draft a section or structured artifact.
  • editor: unify voice, tighten structure, fix inconsistencies.
• Keep each sub-agent task well-scoped and output-oriented.
• Prefer parallel delegation only for independent work. If one result determines the next step, do not parallelize.
• Use list_agents and wait to observe real team state instead of assuming progress.
• When you need to reference a specific dispatched task, track the returned submission_id, not only the agent_id.
• Use fork_context: true only when the child genuinely needs the current conversation context; otherwise keep prompts tighter.
• Team children inherit the parent runtime grant for tools/filesystem/network, but runtime strips further subagent spawning (spawn_agent / legacy Task).
• Do not add blanket constraints like “不要调用任何工具” unless the task truly requires it; role prompts are soft guidance, runtime grant is the hard boundary.

Tools (available only after this Skill is loaded)

• spawn_agent({ agent_type, prompt, description?, fork_context? }) -> { agent_id, submission_id }
• wait({ ids, timeout_ms? }) -> agent statuses + submission statuses/previews
• send_input({ id, prompt, interrupt? }) -> queue more work for that agent and return a new submission_id
• resume_agent({ id }) -> reopen a closed agent so it can receive future work
• close_agent({ id })
• list_agents()

Recommended Workflow (General Team)

1. Orchestrator determines whether the next step is read-only exploration, implementation, review, or synthesis.
2. Spawn only the agents that materially reduce wall-clock time.
3. wait for the blocking agents before the next dependent step.
4. If implementation happened, run a reviewer or explicit verification pass before finalizing.
5. Final answer: one merged result with evidence, changed files, or findings as appropriate.

Lifecycle Notes

• close_agent only stops future queued work. It does not kill in-flight execution.
• resume_agent is for reopening a previously closed agent, not for rewinding history.
• interrupt: true is reserved but not yet implemented as a real preemption primitive. If the target agent is still busy, the tool should fail explicitly instead of pretending success.
• If you pass task_id to spawn_agent and that task is already owned by the current parent agent, runtime will drop the duplicate child binding. If another owner already holds it, spawn_agent fails explicitly and you should retry without task_id when you only need an unbound helper.

Prompt Template

Use this exact structure when delegating:

• Context: target audience, constraints, length, tone
• Deliverable: what to output, format requirements
• Must include: bullet list of required points
• Must avoid: banned content / style