3. Teammates — Roles, Specialties, and Limits

Description

The team lead coordinates. The teammates execute. But "executing" without a clear definition produces the same problems you had with generic subagents in module 1 — unpredictable results, files that shouldn't have been touched, and conflicts between agents working in the same space. A well-defined teammate is a specialized subagent the team lead knows exactly when and for what to invoke.

In this capsule you'll learn to design teammates with clear roles and boundaries. It's not just about creating agent files — it's about designing the team's structure: what each member does, what it does NOT do, which directories it owns, which skills it preloads, and how its description helps the team lead make assignment decisions. A team with well-defined teammates works with minimal coordination. A team with vague teammates requires the team lead to micromanage — and that's exactly what we wanted to avoid.

By the end, you'll have 2-3 teammates configured with complementary roles, explicit boundaries, and descriptions the team lead can use to assign work automatically.

⚠️ EXPERIMENTAL FEATURE

Teammates work as standard subagent files (a stable feature). Their formal integration with Agent Teams is experimental as of March 2026. Everything you configure here also works as a standalone subagent.

Last check: March 2026

Anatomy of a Teammate

It's a subagent file with a team purpose

A teammate is technically identical to a subagent: a Markdown file with YAML frontmatter and a system prompt. The difference is contextual — it's designed to be invoked by a team lead, not directly by the user.

---
name: frontend-agent
description: Implements UI components, pages, and client-side logic. Works exclusively in frontend directories. Expert in React and CSS.
tools: Read, Write, Edit, Glob, Grep, Bash
model: sonnet
maxTurns: 25
---

## Role

You are a frontend specialist on a development team. You receive
task assignments from the team lead. You implement UI components,
pages, and client-side logic.

## Boundaries

You ONLY modify files in:
- src/components/
- src/pages/
- src/styles/
- src/hooks/
- src/utils/client/

You NEVER modify:
- src/api/
- src/models/
- src/services/
- database/
- tests/ (unless specifically asked to fix a frontend test)

## Working Standards
- Follow existing component patterns in the project
- Use TypeScript for all new files
- Every component exports types for its props
- CSS modules for styling, no inline styles
- Report what you created/modified and why

## Output Format

### Task Completion Report
**Task ID:** [assigned ID]
**Status:** DONE | PARTIAL | BLOCKED
**Files modified:** [list]
**Changes:**
1. [file] — [what and why]
**Notes:** [blockers, questions, or dependencies needed]

Fields that matter for the team lead

description — This field is key for Agent Teams. The team lead reads the descriptions of all the teammates to decide who to assign each task to. A vague description ("Handles frontend stuff") produces vague assignments. A precise description ("Implements UI components, pages, and client-side logic. Works exclusively in frontend directories. Expert in React and CSS.") allows informed decisions.

tools — Defines the teammate's real capabilities. A teammate without Write can't create files. One without Bash can't run commands. The tools reinforce the boundaries of the system prompt.

model — Teammates can generally use haiku or sonnet depending on the complexity of their tasks. They don't need opus — that's the team lead's responsibility.

Designing Complementary Roles

The principle of coverage without overlap

A good team covers the whole codebase without two teammates having authority over the same files:

┌─────────────────────────────────────────────┐
│                  CODEBASE                    │
│                                              │
│  ┌──────────────┐  ┌──────────────────────┐  │
│  │  frontend/   │  │  backend/            │  │
│  │  components/ │  │  api/                │  │
│  │  pages/      │  │  models/             │  │
│  │  styles/     │  │  services/           │  │
│  │              │  │  database/           │  │
│  │  FRONTEND    │  │  BACKEND AGENT       │  │
│  │  AGENT       │  │                      │  │
│  └──────────────┘  └──────────────────────┘  │
│                                              │
│  ┌──────────────────────────────────────────┐│
│  │  tests/    config/    docs/              ││
│  │  SHARED ZONE (team lead decides)         ││
│  └──────────────────────────────────────────┘│
└─────────────────────────────────────────────┘

Rule: Every file in the project should have at most one teammate that can modify it. If two teammates can edit the same file, you'll have conflicts. The "shared zone" (tests, config, docs) is managed by the team lead, assigning based on context.

Example: frontend + backend team

frontend-agent:
  OWNS:  src/components/, src/pages/, src/styles/, src/hooks/
  READS: src/types/, src/api/contracts/  (to know the API)
  NEVER TOUCHES: src/api/, src/models/, src/services/, database/

backend-agent:
  OWNS:  src/api/, src/models/, src/services/, database/
  READS: src/types/  (to keep type consistency)
  NEVER TOUCHES: src/components/, src/pages/, src/styles/

tests/ → Assigned by the team lead based on context:
  - Component test → frontend-agent
  - Endpoint test → backend-agent
  - Integration test → whoever has the most context

Example: three-part team (API + DB + Test)

api-dev:
  OWNS:  src/routes/, src/schemas/, src/middleware/
  READS: src/models/  (to know the data types)
  NEVER TOUCHES: src/models/ (read-only), tests/, migrations/

db-dev:
  OWNS:  src/models/, src/repositories/, alembic/
  READS: src/routes/  (to understand how the data is used)
  NEVER TOUCHES: src/routes/ (read-only), tests/, middleware/

test-runner:
  OWNS:  tests/
  READS: all of src/  (to understand what to test)
  NEVER TOUCHES: src/  (read-only), alembic/, config/

Boundaries: More Than Directories

4 types of boundaries

1. File boundaries (directories):

## Boundaries
You ONLY modify files in:
- src/api/routes/
- src/api/schemas/

You NEVER modify files in:
- src/models/ (read-only for context)
- tests/
- config/

2. Operation boundaries (tools):

# Teammate that implements
tools: Read, Write, Edit, Glob, Grep, Bash

# Teammate that only tests
tools: Read, Glob, Grep, Bash
disallowedTools: Write, Edit

3. Decision boundaries (system prompt):

## Decision Boundaries

You make decisions about:
- Component structure and props
- CSS styling approach
- Client-side state management

You do NOT make decisions about:
- API endpoint design (ask backend-agent via team lead)
- Data model structure (accept what db-dev defines)
- Authentication flow (accept what the team lead specifies)

4. Knowledge boundaries (skills):

skills:
  - react-patterns      # Preloaded domain knowledge
  - css-conventions

File boundaries prevent conflicts. Operation ones reinforce restrictions. Decision ones prevent scope creep. Knowledge ones keep the teammate focused on its domain.

Boundaries as a contract

Think of boundaries as a contract between the teammate and the team lead:

CONTRACT: frontend-agent

I CAN:
- Create and modify React components
- Create CSS module files
- Use existing hooks or create new ones
- Install UI dependencies (with approval)

I CANNOT:
- Create API endpoints
- Modify data models
- Change database configuration
- Decide the API structure

I NEED FROM THE TEAM:
- Data types defined by db-dev
- API contracts defined by api-dev
- UX decisions from the team lead

This contract makes the dependencies between teammates explicit — information the team lead uses to coordinate.

Skills: Preloading Domain Knowledge

What they are and when to use them

Skills are knowledge files that are preloaded into the teammate's context. A skill file contains patterns, conventions, or references the teammate needs to work consistently.

skills:
  - react-component-patterns
  - project-style-guide

Claude looks for skills in:

1. .claude/skills/ (project)
2. ~/.claude/skills/ (user)
3. Skills from enabled plugins

Example: frontend conventions skill

Create .claude/skills/react-component-patterns.md:

# React Component Patterns

## File Structure
Every component in a directory with:
- ComponentName.tsx (implementation)
- ComponentName.module.css (styles)
- index.ts (re-export)

## Props Pattern
Always define props interface:
```typescript
interface ProfileCardProps {
  user: User;
  onEdit?: () => void;
  className?: string;
}

State Pattern

• useState for local state
• useContext for shared state
• No Redux — use React Context + useReducer

Naming

• Components: PascalCase
• Hooks: camelCase starting with "use"
• CSS modules: camelCase for class names

With this skill preloaded, the frontend-agent follows these conventions without the team lead repeating them in every assignment.

### Skills vs system prompt

| Aspect | System Prompt | Skills |
|---------|--------------|--------|
| Content | Role, process, format | Domain knowledge |
| Size | Short and focused | Can be extensive |
| Reuse | Specific to the teammate | Shareable between teammates |
| Change | Changes if the role changes | Changes if the conventions change |

Rule: the system prompt defines **what the teammate does**. Skills define **how it does it** according to the project conventions.

---

## Memory Scopes per Teammate

### When to configure memory

In module 2 you learned about memory scopes. For teammates, memory is useful when:

- The teammate runs multiple times and should remember previous decisions
- The team has conventions that are discovered during execution
- You want the teammate to accumulate project knowledge

```yaml
memory: project    # Remembers across sessions for this project
memory: user       # Remembers globally (all projects)

Practical example

---
name: backend-agent
description: Backend specialist for API and data access
memory: project
---

With memory: project, the backend-agent remembers:

• Which endpoints it created in previous sessions
• Which naming conventions it discovered in the project
• Errors it encountered and how it resolved them

Without memory, each run is the first time — which is acceptable for isolated tasks but inefficient for iterative development.

Naming Conventions That Help the Team Lead

Why the name matters

The team lead uses each teammate's name and description to decide assignments. Good names and descriptions produce good automatic assignments.

# ❌ Vague names — the team lead can't differentiate
name: agent-1
description: Does development tasks

name: agent-2
description: Also does development tasks

# ✅ Descriptive names — the team lead knows who does what
name: frontend-agent
description: Implements React components and pages in src/components/ and src/pages/

name: backend-agent
description: Implements FastAPI endpoints and SQLAlchemy models in src/api/ and src/models/

Recommended naming pattern

[domain]-[role]

Examples:
  frontend-agent     → Domain: frontend, Role: general implementer
  backend-agent      → Domain: backend, Role: general implementer
  api-dev            → Domain: API, Role: developer
  db-dev             → Domain: database, Role: developer
  test-runner        → Domain: testing, Role: executor
  security-reviewer  → Domain: security, Role: reviewer
  docs-writer        → Domain: documentation, Role: writer

The description as an assignment spec

The description isn't just metadata — it's the specification the team lead uses to decide. Include:

1. What it does: "Implements React components"
2. Where it works: "in src/components/ and src/pages/"
3. What it's expert in: "Expert in React, TypeScript, and CSS modules"
4. What it does NOT do: (in the system prompt, not in the description)

# ❌ Generic description
description: Frontend development

# ✅ Description as a spec
description: Implements React components, pages, and client-side hooks. Works exclusively in src/components/, src/pages/, src/hooks/. Expert in TypeScript, React Server Components, and Tailwind CSS.

Complete Configuration: Frontend Agent

---
name: frontend-agent
description: Implements React components, pages, and client-side logic. Works exclusively in frontend directories (src/components/, src/pages/, src/hooks/, src/styles/). Expert in TypeScript, React, and CSS modules.
tools: Read, Write, Edit, Glob, Grep, Bash
model: sonnet
maxTurns: 25
skills:
  - react-component-patterns
  - project-style-guide
---

## Role

You are a frontend specialist receiving task assignments from a team lead.
You implement UI components, pages, and client-side logic following
project conventions.

## Boundaries

### Files you OWN (can create and modify):
- src/components/**
- src/pages/**
- src/hooks/**
- src/styles/**
- src/utils/client/**

### Files you READ (for context, never modify):
- src/types/** (shared type definitions)
- src/api/contracts/** (API response shapes)
- CLAUDE.md (project conventions)

### Files you NEVER touch:
- src/api/** (backend territory)
- src/models/** (database territory)
- src/services/** (backend territory)
- database/** (database territory)
- tests/** (unless fixing a specific frontend test)

## Working Standards

1. Every component in its own directory with .tsx, .module.css, and index.ts
2. Props defined as TypeScript interfaces, exported from the component file
3. No inline styles — use CSS modules
4. Custom hooks for shared logic, prefixed with "use"
5. Error boundaries around async components

## When Receiving a Task

1. Read the task description and dependencies
2. Check if prerequisite outputs exist (API types, contracts)
3. Implement following project conventions
4. Self-review: verify TypeScript compiles, no console.logs left
5. Report completion with files changed and rationale

## Output Format

### Task Report
**Task:** [ID and description]
**Status:** DONE | PARTIAL | BLOCKED
**Files:**
- Created: [list]
- Modified: [list]
**Summary:** [what was done and why]
**Dependencies needed:** [if BLOCKED, what's missing]

Complete Configuration: Backend Agent

---
name: backend-agent
description: Implements API endpoints, business logic, and data access layer. Works exclusively in backend directories (src/api/, src/models/, src/services/). Expert in FastAPI, SQLAlchemy, and Pydantic.
tools: Read, Write, Edit, Glob, Grep, Bash
model: sonnet
maxTurns: 25
skills:
  - fastapi-patterns
  - sqlalchemy-conventions
---

## Role

You are a backend specialist receiving task assignments from a team lead.
You implement API endpoints, business logic, and data access following
project conventions.

## Boundaries

### Files you OWN:
- src/api/routes/**
- src/api/schemas/**
- src/models/**
- src/services/**
- src/utils/server/**

### Files you READ:
- src/types/** (shared type definitions)
- CLAUDE.md (project conventions)
- alembic/ (migration history for context)

### Files you NEVER touch:
- src/components/** (frontend territory)
- src/pages/** (frontend territory)
- src/styles/** (frontend territory)
- tests/** (unless fixing a specific backend test)

## Working Standards

1. Every endpoint has a Pydantic request and response model
2. Business logic in services/, not in route handlers
3. Database access through repository pattern
4. All endpoints have error handling (HTTPException with correct codes)
5. Async functions for all database operations

## API Contract Pattern

When creating a new endpoint, also create the type definition
in src/types/ so the frontend-agent can consume it:

```python
# src/api/schemas/profile.py
class ProfileResponse(BaseModel):
    id: int
    username: str
    email: str
    avatar_url: str | None

This schema becomes the contract between you and frontend-agent.

Output Format

Task Report

Task: [ID and description] Status: DONE | PARTIAL | BLOCKED Files:

• Created: [list]
• Modified: [list] API Endpoints: [if applicable]
• [METHOD /path] — [description] Summary: [what was done and why] Dependencies needed: [if BLOCKED, what's missing]

---

## Teammate vs Teammate: Comparison Table

| Aspect | frontend-agent | backend-agent |
|---------|---------------|---------------|
| **Own directories** | components/, pages/, styles/, hooks/ | api/, models/, services/ |
| **Reads without modifying** | types/, api/contracts/ | types/, alembic/ |
| **Model** | sonnet | sonnet |
| **Skills** | react-patterns, style-guide | fastapi-patterns, sqlalchemy |
| **Special tools** | — | Bash (for migrations) |
| **Key output** | Components created, props | Endpoints created, schemas |
| **Depends on** | Backend API contracts | Shared types |
| **Publishes for** | — | Types in src/types/ |

The table makes visible how the teammates complement each other: the backend publishes API contracts that the frontend consumes. The frontend doesn't need to know how the API works internally — only the shape of the response.

---

## Manual Alternative: Teammates Without Agent Teams

If Agent Teams isn't available, the teammates work as standard subagents invoked by a coordinator:

```markdown
---
name: coordinator
tools: Agent(frontend-agent), Agent(backend-agent), Read, Glob, Grep
model: sonnet
---

## Teammate Management

When delegating to a teammate:
1. Include the task ID and full description
2. Specify which files to work in
3. Provide any outputs from prior tasks as context
4. Request the standard Task Report format

Example delegation:
"Task T3: Implement ProfilePage component in src/components/.
 Use the ProfileResponse type from src/types/profile.ts (created in T1).
 Follow react-component-patterns conventions.
 Report: files created, props defined, and status."

The teammates' agent files are identical in both cases. The difference is how they're coordinated: with Agent Teams the team lead has coordination primitives; without them, the logic is in the coordinator's system prompt.

Troubleshooting

"The team lead assigns tasks to the wrong teammate"

Cause: The teammate descriptions don't clearly differentiate their domains.

Solution: In the description, include:

• Which directories it owns (not just "frontend" — list the paths)
• Which technologies it's expert in
• What kind of tasks it handles (components, endpoints, tests)

"A teammate modifies another teammate's files"

Cause: The boundaries aren't reinforced by tools, only by the system prompt.

Solution: Add a PreToolUse hook that validates the path:

#!/bin/bash
# .claude/hooks/validate-frontend-boundaries.sh
if [[ "$AGENT_NAME" == "frontend-agent" ]]; then
  FILE=$(echo "$TOOL_INPUT" | jq -r '.file_path // .path // empty')
  if [[ -n "$FILE" && ! "$FILE" =~ ^src/(components|pages|styles|hooks)/ ]]; then
    echo "BLOCKED: frontend-agent cannot modify $FILE"
    exit 2
  fi
fi

"The teammates don't follow the project conventions"

Cause: There are no preloaded skills or the system prompt doesn't reference CLAUDE.md.

Solution:

1. Create skills with the project conventions
2. Reference the skills in the teammate's frontmatter
3. In the system prompt, add: "Read CLAUDE.md before starting any task"

"A teammate reports BLOCKED but the team lead doesn't react"

Cause: The team lead has no instructions on what to do with the BLOCKED status.

Solution: In the team lead's system prompt, add:

When a teammate reports BLOCKED:
1. Read the "Dependencies needed" section
2. Check if another teammate can provide what's needed
3. If yes, assign a task to that teammate first
4. If no, report the blocker to the user

"The teammates produce outputs in different formats"

Cause: Each teammate has a slightly different output format or doesn't follow it.

Solution: Standardize the output format in a shared skill:

# .claude/skills/task-report-format.md
## Standard Task Report

All teammates MUST use this exact format:

### Task Report
**Task:** [ID] — [description]
**Status:** DONE | PARTIAL | BLOCKED
**Files:** [list of created/modified]
**Summary:** [1-2 sentences]
**Dependencies needed:** [if BLOCKED]

And reference it in each teammate: skills: [task-report-format, ...]

Exercises

Exercise 1: Minimal teammate (Easy)

Create a docs-writer teammate that generates documentation. It can only read code and write files in docs/. It can't modify source code or run commands.

---
name: docs-writer
description: Generates documentation from code analysis. Writes to docs/ directory only. Expert in API documentation and README files.
tools: Read, Glob, Grep, Write
disallowedTools: Edit, Bash
model: haiku
maxTurns: 15
---

## Role
Documentation specialist. You read code and produce documentation.
You NEVER modify source code.

## Boundaries
- WRITE to: docs/ directory only
- READ: entire codebase for context
- NEVER modify: src/, tests/, config/

## Output Format
### Task Report
**Task:** [ID]
**Status:** DONE | PARTIAL
**Files created:** [list in docs/]
**Summary:** [what was documented]

Exercise 2: Identify missing boundaries (Easy)

This teammate has boundary problems. Identify 4 problems and fix them:

---
name: full-stack
description: Does everything
tools: Read, Write, Edit, Bash, Glob, Grep
model: sonnet
---

You are a full-stack developer. Implement whatever is asked.

---
name: fullstack-dev
description: Implements features that span frontend and backend. Works in src/components/, src/api/, and src/services/. Expert in React + FastAPI integration.
tools: Read, Write, Edit, Bash, Glob, Grep
model: sonnet
maxTurns: 30
---

## Role
Full-stack developer. Implements features that require
both frontend and backend changes.

## Boundaries
- MODIFY: src/components/, src/api/, src/services/
- READ: src/models/, src/types/, CLAUDE.md
- NEVER: database/, alembic/, tests/

## Output Format
### Task Report
**Task:** [ID]  **Status:** DONE | PARTIAL | BLOCKED
**Frontend files:** [list]
**Backend files:** [list]
**Summary:** [what and why]

Exercise 3: Design a team of 3 teammates (Medium)

Design 3 teammates for a Python/Django project with a React frontend. Define: name, description, boundaries (OWNS, READS, NEVER TOUCHES), and a skill each one would need. Draw the codebase coverage diagram.

CODEBASE COVERAGE:

frontend-agent:     react-app/src/ (components, pages, hooks)
django-dev:         backend/ (views, serializers, urls, services)
db-dev:             backend/models/, migrations/

Shared (team lead):  tests/, docs/, config/

Exercise 4: Skill file for your project (Medium)

Create a skill file that captures the conventions of your current project. Include: file structure, code patterns (with examples), naming conventions, and common mistakes to avoid. Then associate it with a teammate.

# FastAPI Project Conventions

## Directory Structure
src/
├── routes/       # One file per resource (users.py, products.py)
├── schemas/      # Pydantic models, one file per resource
├── models/       # SQLAlchemy models
├── services/     # Business logic (no HTTP, no DB imports)
├── repositories/ # Database access (no business logic)
└── core/         # Config, deps, security

## Route Pattern
@router.get("/{id}", response_model=schemas.UserResponse)
async def get_user(id: int, service: UserService = Depends()):
    return await service.get_by_id(id)

## Naming
- Routes: plural nouns (users, products)
- Schemas: ResourceAction (UserCreate, UserResponse)
- Services: ResourceService (UserService)
- Repositories: ResourceRepository (UserRepository)

## Common Mistakes to Avoid
- Business logic in route handlers (put in services)
- Direct DB access in routes (use repositories)
- Missing response_model on routes
- Sync functions for DB operations (use async)

skills:
  - fastapi-project-conventions

Exercise 5: Boundary validation hook (Hard)

Write a PreToolUse hook that validates that each teammate only modifies files inside its boundaries. The hook must:

1. Detect which teammate is executing
2. Verify that the file path is inside the allowed boundaries
3. Block the operation if it's outside the boundaries (exit code 2)

#!/bin/bash

TOOL_NAME="$1"
TOOL_INPUT="$2"
AGENT_NAME="${CLAUDE_AGENT_NAME:-unknown}"

if [[ "$TOOL_NAME" != "Write" && "$TOOL_NAME" != "Edit" ]]; then
  exit 0
fi

FILE=$(echo "$TOOL_INPUT" | jq -r '.file_path // .path // empty')
if [[ -z "$FILE" ]]; then
  exit 0
fi

case "$AGENT_NAME" in
  frontend-agent)
    if [[ ! "$FILE" =~ ^src/(components|pages|styles|hooks|utils/client)/ ]]; then
      echo "BLOCKED: $AGENT_NAME cannot modify $FILE (outside frontend boundaries)"
      exit 2
    fi
    ;;
  backend-agent)
    if [[ ! "$FILE" =~ ^src/(api|models|services|utils/server)/ ]]; then
      echo "BLOCKED: $AGENT_NAME cannot modify $FILE (outside backend boundaries)"
      exit 2
    fi
    ;;
esac

exit 0

{
  "hooks": {
    "PreToolUse": [
      { "command": ".claude/hooks/validate-teammate-boundaries.sh" }
    ]
  }
}

Exercise 6: Teammate with memory and accumulated context (Hard)

Configure an api-dev teammate with project memory scope. Run it on a task, verify that the memory was saved, and then run it on a second task. Compare: was the second run more efficient? Did the teammate remember conventions from the first?

---
name: api-dev
description: API endpoint developer with project memory
memory: project
model: sonnet
tools: Read, Write, Edit, Glob, Grep, Bash
maxTurns: 20
---

## Role
API developer. You remember context from prior tasks in this project.

## Memory Usage
- When you discover project conventions, remember them
- When you make decisions about patterns, record the reasoning
- When you encounter errors, remember the resolution

## First Task Behavior
- Read CLAUDE.md and existing code to discover conventions
- Note patterns: naming, structure, error handling style
- Implement the task following discovered conventions

## Subsequent Task Behavior
- Use remembered conventions without re-reading everything
- Verify if conventions have changed (check file dates)
- Build on prior decisions for consistency

Summary

• A teammate is a subagent file designed to be invoked by a team lead — technically the same, conceptually different
• The description is the most important piece for Agent Teams — the team lead uses it to decide assignments
• The boundaries define what each teammate can modify — coverage without overlap avoids conflicts
• There are 4 types of boundaries: files (directories), operations (tools), decisions (system prompt), and knowledge (skills)
• Skills preload domain knowledge — conventions the teammate follows automatically
• The naming follows the [domain]-[role] pattern — descriptive for humans and for the team lead
• Each teammate produces a standardized Task Report the team lead can process
• Without Agent Teams, the teammates work as standard subagents invoked by a coordinator — the agent files are identical

Additional Resources

1. Create Custom Subagents (Anthropic Docs) — Official documentation of agent files with YAML frontmatter
2. Claude Code Hooks Reference — PreToolUse hooks for boundary enforcement
3. Claude Code Best Practices — Delegation and specialization best practices
4. Prompt Engineering: Be Clear and Direct — Clarity techniques applicable to descriptions and boundaries
5. Claude Code Settings — Skills and hooks configuration
6. Claude Code CLI Reference — The --agent flag and agent file management
7. Principle of Least Privilege (OWASP) — The security foundation behind restrictive boundaries
8. Claude Code Overview — General context to understand how teammates fit in

Next capsule: In capsule 04 you'll learn to create and manage the task board — the list of tasks with dependencies, priorities, and states the team lead uses to coordinate the team. You'll see how to declare dependencies between tasks, how the team lead resolves the execution order, and what happens when a dependency isn't met.