# Team

> Team allocation and dependency-aware parallelization — decide when to use teams, select roles, dispatch parallel work safely. Invoke for L-size tasks to evaluate whether team dispatch reduces wall-clock time.

- **Type:** Skill
- **Install:** `agentstack add skill-cookys-autopilot-team`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [cookys](https://agentstack.voostack.com/s/cookys)
- **Installs:** 0
- **Category:** [Communication](https://agentstack.voostack.com/c/communication)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [cookys](https://github.com/cookys)
- **Source:** https://github.com/cookys/autopilot/tree/develop/skills/team

## Install

```sh
agentstack add skill-cookys-autopilot-team
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Team Allocation

## Coexistence with Superpowers

This skill is autopilot's standalone methodology for *team allocation decisions* — when to organize parallel work, which roles to assign, how to analyze dependencies. If the `superpowers` plugin is installed, `superpowers:dispatching-parallel-agents` is the **dispatch mechanism** (the verb), but role/dependency planning (the noun) is still this skill's domain.

Differences worth knowing:

- **autopilot:team** = allocation decision tree (when to組隊, role 選擇, 依賴分析, team size rules, shutdown flow).
- **superpowers:dispatching-parallel-agents** = the technical dispatch mechanism — issuing parallel agent calls with structured reporting.
- For the dispatch mechanism preference (after allocation decided), see `.claude/dispatch-config.md`'s `## Parallel Dispatch` chain. For allocation methodology, this skill is the primary entry point regardless.

## Project Config (auto-injected)
!`cat .claude/team-config.md 2>/dev/null || echo "_No config — using generic role templates below._"`

## When Teams Are Needed

| Size | Team | Action |
|------|------|--------|
| S | No | Do directly |
| L | Evaluate | Use decision tree below |

## Decision Tree

```
L-size task
├── All phases sequentially dependent? → No team, solo by phase
├── 2+ independent parallel work blocks? → Build team
│   ├── Backend + Frontend changes   → backend-dev + frontend-dev
│   ├── Audit then implement         → auditor + implementer
│   ├── Multiple modules each need changes → per-module agents
│   └── Research + implement can overlap   → researcher + implementer
└── Unsure? → Solo Phase 0 design first, then decide
```

## Role Templates

| Role | subagent_type | Use Case |
|------|--------------|----------|
| backend-dev | `general-purpose` | Backend/server changes |
| frontend-dev | `general-purpose` | Frontend/client changes |
| auditor | `Explore` | Code audit, investigation |
| researcher | `Explore` | Architecture research, comparison |
| tester | `general-purpose` | E2E/stress testing |

## Team Size Rules

- **Minimize**: 2 agents sufficient? Do not use 3.
- **Cap at 3**: Coordination cost exceeds parallelism benefit beyond 3.
- **Leader = self**: Main agent coordinates. Do not spawn a separate leader.

> **cap-3 governs COORDINATION, i.e. collaborative teams (agents that message / share state) — NOT
> independent read-only fan-out.** Spawning N agents that each produce findings/reports over disjoint
> inputs and never write back to shared files (e.g. `audit` Phase 2 per-segment exploration, parallel
> review dimensions, multi-source research) is **not a team and is not capped at 3** — there's no
> inter-agent coordination to pay for. Bound such fan-out by the practical concurrency sweet spot (~8)
> and assert *collected == dispatched* before synthesizing, so a dropped unit fails loudly instead of
> silently thinning the result.

## Dependency Analysis

Details on dependency graph construction, file overlap checks, and common parallelization patterns: [references/team-tactics.md](references/team-tactics.md)

## Execution

### Create Team

```
TeamCreate:
  team_name: ""
  description: ""
```

### Create Tasks

One task per parallelizable work unit:
```
TaskCreate:
  subject: "Phase N: "
  description: "Full description including:
    - Files to modify
    - Completion criteria
    - Verification method"
  activeForm: "Working on Phase N"
```

### Spawn Teammates

```
Agent tool:
  subagent_type: ""
  team_name: ""
  name: ""
  prompt: |
    You are , responsible for ...

    ### SKILLS — Invoke these via the Skill tool before touching code
    - /:   # e.g. /autopilot:debug if this teammate will touch
                          # failure-prone code
    - /:  # project skill for the affected module, if any
    - none — explain why  # explicit fallback when no skill applies

    
```

Paraphrasing a skill's methodology inside `` is NOT
a substitute for the SKILLS block. The subagent must call the Skill tool so the
skill's full checklist / red-line rules / rationalization table load into its
session context — same discipline dev-flow L-1.6 enforces on the main session,
applied to subagent dispatch. For the full Seven-Element template (including
SKILLS) when dispatching L-size project work, see
`skills/ceo-agent/references/task-prompt-templates.md`.

### Coordination Principles

1. **Task-driven**: Each teammate picks work from TaskList
2. **Concise messaging**: SendMessage only when coordination needed
3. **Leader does not implement**: Leader coordinates + reviews, does not take tasks
4. **Report on completion**: Teammate does TaskUpdate + SendMessage when done
5. **Timely shutdown**: All tasks complete -> run shutdown flow

### Shutdown

```
All tasks completed
├── 1. Confirm all TaskUpdate status=completed
├── 2. Leader reviews each teammate's output
├── 3. TeamDelete team_name=""
└── 4. Report final results to user
```

## Anti-patterns

| Wrong | Correct |
|-------|---------|
| "I'll do it faster solo" | Evaluate objectively — 2 modules = worth parallelizing |
| Team commit task says "commit changes" | Must include quality-pipeline |
| Dispatch without file overlap check | Always check overlap first |
| Dispatch teammate prompt without `### SKILLS` section | Subagent must invoke required skills via the Skill tool before touching code; paraphrasing the methodology in the prompt loses fidelity (same rule as ceo-agent step 9 and dev-flow L-1.6) |

## See Also

- [Dependency Analysis + Parallelization Tactics](references/team-tactics.md)
- `autopilot:dev-flow` — orchestrates team evaluation at L-4

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [cookys](https://github.com/cookys)
- **Source:** [cookys/autopilot](https://github.com/cookys/autopilot)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-cookys-autopilot-team
- Seller: https://agentstack.voostack.com/s/cookys
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.