Token导航 LogoToken导航TokenDH.com
研究检索执行命令github未标认证来源可访问许可证需确认审计通过

agent-teamsAgent Teams 协作

Agent Skill

agent-teams 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。可结合来源仓库、安装命令和原始 README 继续核验具体用法。安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。

总安装

682

周安装

29

GitHub Stars

28

下载量

239
CodexClaudeCursorGemini CLI

安装说明

本站只整理中文说明和来源信息,不托管安装包,也不代用户安装。

GitHub

来源数

2

许可证

unknown

最后核验

2026-05-01

来源状态

来源可访问

安装方式

通过对话安装

复制提示词发给支持本地命令或 Skills 的 AI 助手,先确认命令和权限,再让它执行。

请帮我安装这个 Agent Skill:agent-teams(Agent Teams 协作)
来源仓库:https://github.com/laurigates/claude-plugins
仓库路径:skills/agent-teams
安装命令:
npx skills add https://github.com/laurigates/claude-plugins --skill agent-teams
安装前请先检查当前环境是否支持对应 CLI,并向我确认将要执行的命令、安装目录、联网范围和文件读写权限;确认后再执行。

命令行安装

复制命令到本机终端执行。该命令会通过 npx skills 从第三方来源获取 Skill;本站只展示命令,不托管安装包,也不自动执行。

skills.shnpx skills
npx skills add https://github.com/laurigates/claude-plugins --skill agent-teams

简介

agent-teams 用于查找、检索和筛选相关信息,适合在 Codex、Claude、Cursor、Gemini CLI 中需要根据关键词、任务场景或来源线索快速定位候选结果时使用。

  • 它可结合来源仓库、安装命令和原始 README 继续核验具体用法。
  • 安装前建议确认权限范围、维护状态,以及是否会触发联网、命令执行或文件读写。
  • 当前顶部介绍为空,需参考原始 SKILL.md 进一步了解功能细节。
  • 适用宿主包括 Codex、Claude、Cursor、Gemini CLI,接入前应确认版本、权限和运行环境要求。

SKILL.md

Agent Teams

Experimental: Agent teams require the --enable-teams flag and may change between Claude Code versions.

When to Use This Skill

Use agent teams when...Use subagents instead when...
Multiple agents need to work in parallelTasks are sequential and interdependent
Ongoing communication between agents is neededOne focused task produces one result
Background tasks need progress reportingAgent output feeds directly into next step
Complex workflows benefit from task coordinationSimple, bounded, isolated execution
Independent changes to the same codebase (with worktrees)Context sharing is fine and efficient

Core Concepts

Team Architecture

Lead Agent (orchestrator)
    ├── TeamCreate — creates team + shared task list
    ├── Agent tool — spawns teammate agents
    ├── SendMessage — communicates with teammates
    ├── TaskUpdate — assigns tasks to teammates
    └── Teammates (run in parallel)
            ├── Read team config from ~/.claude/teams/<name>/config.json
            ├── TaskList/TaskUpdate — claim and complete tasks
            └── SendMessage — report back to lead

Native Team Tools

ToolPurpose
TeamCreateCreate team and shared task list directory
TeamDeleteClean up team when all work is complete
SendMessageSend DMs, broadcasts, shutdown requests, plan approvals
TaskOutputGet output from a background agent
TaskStopStop a running background agent

Team Setup Workflow

1. Create the Team

TeamCreate({
  team_name: "my-project",
  description: "Working on feature X"
})

This creates:

  • ~/.claude/teams/<team-name>/ — team config directory
  • ~/.claude/tasks/<team-name>/ — shared task list directory

2. Create Initial Tasks

TaskCreate({
  team_name: "my-project",
  title: "Implement security review",
  description: "Audit auth module for vulnerabilities",
  status: "pending"
})

3. Spawn Teammates

Use the Agent tool to spawn each teammate with the team context:

Agent tool with:
  subagent_type: "agents-plugin:security-audit"
  team_name: "my-project"
  name: "security-reviewer"
  prompt: "Join team my-project and work on security review task..."

4. Assign Tasks

TaskUpdate({
  team_name: "my-project",
  task_id: "task-1",
  owner: "security-reviewer",
  status: "in_progress"
})

5. Receive Results

Teammates send messages automatically — they are delivered to the lead's inbox between turns. No polling needed.

Task Management

Task States

StateMeaning
pendingNot yet started
in_progressAssigned and active (one at a time per teammate)
completedFinished successfully
blockedWaiting on another task

Task Priority

Teammates should claim tasks in ID order (lowest first) — earlier tasks often set up context for later ones.

TaskList Usage

Teammates should check TaskList after completing each task to find available work:

TaskList({ team_name: "my-project" })
→ Returns all tasks with status, owner, and blocked-by info

Claim an unassigned task:

TaskUpdate({ team_name: "my-project", task_id: "N", owner: "my-name" })

Communication (SendMessage)

Message Types

TypeUse When
messageDirect message to a specific teammate
broadcastCritical team-wide announcement (use sparingly — expensive)
shutdown_requestAsk a teammate to gracefully exit
shutdown_responseApprove or reject a shutdown request
plan_approval_responseApprove or reject a teammate's plan

DM Example

SendMessage({
  type: "message",
  recipient: "security-reviewer",  // Use NAME, not agent ID
  content: "Please also check the payment module",
  summary: "Adding payment module to scope"
})

Broadcast (use sparingly)

SendMessage({
  type: "broadcast",
  content: "Stop all work — critical blocker found in auth module",
  summary: "Critical blocker: halt work"
})

Broadcasting sends a separate delivery to every teammate. With N teammates, that's N API round-trips. Reserve for genuine team-wide blockers.

Teammate Behavior

Discovering Team Members

Read the team config to find other members:

Read ~/.claude/teams/<team-name>/config.json
→ members array with name, agentId, agentType

Always use the name field (not agentId) for recipient in SendMessage.

Idle State

Teammates go idle after every turn — this is normal. Idle ≠ unavailable. Sending a message to an idle teammate wakes them.

Key Teammate Rules

  • Mark exactly ONE task in_progress at a time
  • Use TaskUpdate (not SendMessage) to report task completion
  • System sends idle notifications automatically — no need for status JSON messages
  • All communication requires SendMessage — plain text output is NOT visible to the team lead

Shutdown Procedures

Graceful Shutdown (Lead → Teammates)

SendMessage({
  type: "shutdown_request",
  recipient: "security-reviewer",
  content: "All tasks complete, wrapping up"
})

Teammate Approves Shutdown

SendMessage({
  type: "shutdown_response",
  request_id: "<id from shutdown_request JSON>",
  approve: true
})

Cleanup (Lead)

After all teammates shut down:

TeamDelete()
→ Removes ~/.claude/teams/<name>/ and ~/.claude/tasks/<name>/

TeamDelete fails if teammates are still active.

Lead Preflight Checklist

Before drafting the PRP and launching agents, run these checks:

CheckCommandWhy
Next ADR/PRD/PRP sequence number`ls docs/blueprint/adrs/ \sort -V \tail -1`Prevents numbering collisions when agents write docs in parallel
Filename conflicts`git ls-files \grep <filename>`Agent scope tables can't guard against a stale mental model of the tree
Hardware pin budget (embedded)Read pin_config.h or equivalentPrevents pin assignments overlapping across Phase 1 agents

A 30-second sweep prevents multi-edit renaming work after agents return.

Out-of-Scope Discovery Protocol

Include this protocol in every agent's prompt when that agent has an exclusive write scope:

### Out-of-scope discovery protocol

If you discover that a file outside your declared write scope needs to change
for your deliverables to work:

1. **STOP immediately.** Do not read, investigate, or edit the out-of-scope file.
2. In your final summary, include a section titled `Out-of-scope dependencies` that lists:
   - The file(s) that need changes
   - What changes are needed (one line each)
   - Which of your deliverables is blocked without those changes
3. Exit. The lead will triage and either expand your scope, reassign to another agent,
   or handle it directly.

This prevents the "investigate out of scope → exhaust budget → truncated summary" failure mode. The lead can then address the dependency before the next phase or assign a follow-up issue.

Common Patterns

Parallel Code Review

TeamCreate: "code-review"
Tasks: security-audit, performance-review, correctness-check
Teammates: security-agent, performance-agent, correctness-agent (all parallel)
Lead: collects results, synthesizes findings

Parallel Implementation with Worktrees

TeamCreate: "feature-impl"
Tasks: backend-api, frontend-ui, tests
Teammates: each spawned with isolation: "worktree"
Lead: delegates git push (sub-agents must not push independently in sandbox)

Multi-Phase Architecture Refactor

Phase 1 (3 parallel):  Framework upgrade + new module scaffolding + ADR draft
Phase 2 (1 serialized): Reactive executor — depends on Phase 1 contracts
Phase 3 (1 serialized): Wire-up + legacy deletion — exclusive main.c owner
Phase 4 (2 parallel):  Host tests + documentation finalization

Key rules:
- One owner per file across ALL phases (exclusive write scope per agent)
- "Agent writes, lead commits" — keep branch coherent between phases
- Phase boundaries = commit points (clean checkpoint semantics)
- Phase 3 deletion runs AFTER Phases 1–2 finalize their contracts

Real-world outcome: +1850/−1826 lines, zero file-scope collisions across 6 agents, tests exposed a bug on first build. See also: the Out-of-Scope Discovery Protocol above — include it in every focused-scope agent prompt.

Blocked Task Resolution

If a task is blocked on another, set the blocked_by field in TaskCreate. Teammates check TaskList and skip blocked tasks until the blocking task is completed.

Team Roles

RoleBehaviorWhen to Use
LeadOrchestrates, assigns tasks, receives resultsAlways — coordinates the team
TeammateParallel execution with messagingOngoing collaboration, progress reporting
SubagentFocused, isolated, returns single resultSimple bounded tasks, no coordination needed

Sandbox Considerations

In web sessions (CLAUDE_CODE_REMOTE=true):

  • Sub-agents (teammates) may encounter TLS errors on git push — delegate all push/PR operations to the lead
  • Each teammate runs in its own process context
  • Worktree isolation is recommended for independent filesystem changes

Agentic Optimizations

ContextApproach
Quick parallel reviewSpawn 2–4 teammates, broadcast task assignments
Large codebase splitAssign directory subsets as separate tasks
Long-running workBackground teammates, poll via TaskList
Minimize API costPrefer message over broadcast
Fast shutdownSend shutdown_request to each teammate, then TeamDelete

Quick Reference

Workflow Checklist

  • TeamCreate with team name and description
  • TaskCreate for each work unit
  • Spawn teammates via Agent tool with team_name and name
  • TaskUpdate to assign tasks to teammates (or let teammates self-assign)
  • Receive messages automatically; respond via SendMessage
  • SendMessage shutdown_request to each teammate when done
  • TeamDelete after all teammates shut down

Key Paths

PathContents
~/.claude/teams/<name>/config.jsonTeam members (name, agentId, agentType)
~/.claude/tasks/<name>/Shared task list directory

Common Mistakes

MistakeCorrect Approach
Using agentId as recipientUse name field from config.json
Sending broadcast for every updateUse message for single-recipient comms
Polling for messagesMessages delivered automatically — just wait
Sending JSON status messagesUse TaskUpdate for status, plain text for messages
Sub-agent pushes to remoteDelegate push to lead orchestrator
TeamDelete before shutdownShutdown all teammates first

Related Rules

  • .claude/rules/agent-development.md — agent file structure, model selection, worktree isolation
  • .claude/rules/agentic-permissions.md — granular tool permission patterns
  • .claude/rules/sandbox-guidance.md — web sandbox constraints and push delegation

适合场景

01

用户想查找某类 Agent Skill 时

02

需要根据任务场景推荐可安装能力包时

03

需要对比不同来源的安装命令和来源信息时

能力概览

能力 1

按任务关键词查找相关 Skills

能力 2

展示可复制的安装命令

能力 3

保留来源站点、仓库和原始说明,方便继续核验

能力 4

展示第三方安全扫描或审计结果

安装后应在对应宿主中按原始 README 的触发条件使用;具体调用方式请以来源页面和 README 为准。

平台分布

Codex

34.81%
按下载量换算83

Claude

33.14%
按下载量换算79

Cursor

19.72%
按下载量换算47

Gemini CLI

10%
按下载量换算24

安全审计

Gen Agent Trust Hub

通过

Socket

通过

Snyk

通过

权限和风险

执行命令

安装流程涉及命令执行,可能通过 npx skills add https://github.com/laurigates/claude-plugins --skill agent-teams 联网下载 Skill 或依赖。用户安装前应确认命令来源、仓库内容和执行环境。

安装前确认

本站仅展示第三方公开信息,不托管安装包,不提供自动安装或运行环境。安装前应自行审查源码、依赖和命令行为。当前只有一个来源,正式发布前建议补源仓库或其他目录站核验。

来源信息

继续浏览同类 Skills