Team Skill

Coordinate named agents as a team with inter-agent messaging, shared context, file ownership, and leader-managed lifecycle.

Usage

/team [task description]
/team --roles architect,executor,qa-tester [task description]
/team --max-members 3 [task description]
/team --timeout 15 [task description]
/team --dry-run [task description]

Arguments

--roles

--max-members

--timeout

--dry-run

How It Works

You are the team leader. Your job is to orchestrate a coordinated team of specialist agents.

Phase 1: INIT — Analyze and Compose Team

1. Analyze the user's task description
2. Determine which roles are needed:

   • architect

     — for design, schema, API structure decisions

   • executor

     — for implementation (spawn multiple if independent files)

   • qa-tester

     — for writing tests and verification

   • code-reviewer

     — for review passes
   • Other roles from the existing droid registry as needed
3. If

   --roles

   is specified, use those roles directly
4. If

   --dry-run

   is specified, show the plan and stop

Phase 2: DELEGATE — Assign Work

1. Break the task into concrete assignments with:
   • Clear description of what each member should do
   • File ownership (which files each member is responsible for)
   • No file overlap — each file belongs to exactly one member
2. Send task assignments to each member via mailbox
3. Spawn member agents in background with:
   • Role-appropriate subagent type
   • Scoped tool set (via MemberToolPolicy)
   • Shared context injected into prompt
   • File ownership boundaries

Phase 3: COORDINATE — Monitor and Adjust

1. Poll member status periodically
2. Handle incoming messages from members:
   • Results: Update assignment status
   • Questions: Answer or route to appropriate member
   • Permission requests: Approve read-only tools, review destructive tools
3. Detect stale members (no heartbeat > 5 min) and reassign if needed
4. If a critical member (architect) fails, consider aborting

Phase 4: COLLECT — Gather Results

1. Collect all completed results
2. Check for file conflicts (shouldn't happen with ownership, but verify)
3. Aggregate findings into shared context

Phase 5: FINALIZE — Verify and Wrap Up

1. Run verification:

   tsc --noEmit

   ,

   npm test

   ,

   npm run lint

   (as applicable)
2. Broadcast shutdown to all members
3. Report final summary to user

Dry-Run Output

When

--dry-run

[TEAM PLAN]
Task: Add REST API endpoint for user preferences
Members:
  - architect-1 (architect): Design API schema and endpoint structure
  - executor-1 (executor): Implement controller and service layer
  - executor-2 (executor): Implement database migration and model
  - qa-tester-1 (qa-tester): Write integration tests

File Ownership:
  - executor-1: src/controllers/preferences.ts, src/services/preferences.ts
  - executor-2: src/models/preferences.ts, migrations/

Estimated: 4 agents, ~10 min
Proceed? [Y/n]

Team Status Display

During execution, show periodic status updates:

[TEAM: api-build]
├ ✓ architect-1 completed — API schema defined
├ → executor-1 working — implementing controller
├ → executor-2 working — implementing migration
└ 1/3 completed

Error Handling

• If a non-critical member fails, skip or reassign
• If architect fails with no replacement, abort team and report to user
• If timeout is reached, collect whatever results are available and finalize

Integration

• Works with

  /ralph

  for team-level persistence loops
• Shared context is available to all members without explicit message passing
• File ownership prevents conflicts when multiple executors work in parallel

Anti-Patterns

1. Over-staffing — Don't spawn 5 agents for a task that one executor can handle
2. Missing architect — Complex tasks need an architect to design before executors implement
3. No file ownership — Without ownership, parallel executors will conflict on the same files
4. Ignoring stale members — Always check heartbeats and reassign if a member goes silent