5. Messaging Between Teammates and Conflict Resolution

Description

A team where the members don't communicate is a group of individuals working in parallel — not a team. So far you have a team lead that assigns tasks and teammates that execute. But what happens when the frontend-agent needs to know the exact shape of the backend-agent's response? When two teammates modify files that interact? When one finishes before the others and there's nothing to assign it?

In this capsule you'll learn the communication mechanisms between teammates: how they exchange information through the team lead, how conflicts are resolved when two agents produce incompatible results, what the team lead does when a teammate goes idle, and the most common failure modes of an agent team. These patterns are the difference between a team that produces coherent results and one that produces disconnected fragments.

⚠️ EXPERIMENTAL FEATURE

The messaging mechanisms between teammates depend on the Agent Teams implementation in Claude Code. The conceptual model (the team lead as a communication intermediary) is stable. The patterns in this capsule apply both with formal Agent Teams and with the manual coordinator alternative.

Last check: March 2026

How the Teammates Communicate

The team lead as intermediary

The teammates don't communicate directly with each other. All communication passes through the team lead:

frontend-agent ←──→ Team Lead ←──→ backend-agent
                        ↑
                   (intermediary)

When the frontend-agent needs information from the backend-agent:

1. frontend-agent reports: "BLOCKED — I need the ProfileResponse schema"
2. Team lead reads frontend-agent's report
3. Team lead checks whether backend-agent already produced that schema
4. If yes → team lead passes the information to frontend-agent
5. If no → team lead assigns to backend-agent: "Publish the ProfileResponse schema"
6. When backend-agent finishes → team lead passes the result to frontend-agent

Types of communication

1. Output forwarding — passing results:

The most common type. The team lead takes one teammate's output and includes it as context when assigning a task to another:

## For frontend-agent:
Task T4: Implement ProfilePage.

Context from backend-agent (T2):
- GET /api/profile returns ProfileResponse:
  { id: int, username: str, email: str, avatar_url: str | None }
- Endpoint is at src/api/routes/profile.py
- Auth required: Bearer token in header

The team lead doesn't just pass the output — it processes it and extracts the relevant information for the next teammate.

2. Query — a teammate needs information:

frontend-agent: "What's the backend's error format?
                 I need to know which fields the error response has
                 to show appropriate messages."

Team lead:
  → Checks whether backend-agent already defined the format
  → If yes, extracts the information and passes it
  → If no, creates a micro-task for backend-agent:
    "Define and document the standard error response format"

3. Notification — informing of a change:

backend-agent: "I changed the field name 'user_name' to 'username'
                in ProfileResponse."

Team lead:
  → Checks whether any other teammate already used 'user_name'
  → If frontend-agent already implemented with 'user_name',
    assigns an update task
  → If not, simply logs it for future reference

Messaging instructions for the team lead

## Communication Management

### When forwarding outputs
- Extract ONLY the relevant information for the receiving teammate
- Include: data schemas, file paths, API contracts, decisions made
- Exclude: internal implementation details, tool calls, reasoning

### When a teammate queries for information
1. Check if the answer exists in a prior teammate's output
2. If yes → forward the relevant part
3. If no → create a micro-task for the teammate who can answer
4. Micro-tasks have HIGH priority (they unblock other teammates)

### When a teammate reports a change
1. Check if the change affects other teammates' work
2. If yes → notify affected teammates with specific impact
3. If no → log and continue

### Communication Log
After each communication, log:
- FROM: [teammate]
- TO: [teammate]
- TYPE: output_forward | query | notification
- CONTENT: [summary]

Conflict Resolution

Scenario: contradictory outputs

Two teammates produce results that contradict each other:

backend-agent: "I created GET /profile that returns { user: { name, email } }"
frontend-agent: "I created ProfilePage expecting { profile: { username, email } }"

Two inconsistencies:

1. Root field: user vs profile
2. Field name: name vs username

The resolution process

## Conflict Resolution Process

When two teammates produce incompatible results:

### Step 1: Identify the conflict
- Compare outputs side by side
- List specific incompatibilities
- Determine which teammate's output is the "source of truth"

### Step 2: Decide who adjusts
Priority for "source of truth":
1. The teammate closer to the data source wins (backend > frontend for API)
2. The teammate who completed first wins (if both are equal authority)
3. The team lead decides based on project conventions

### Step 3: Assign correction
Assign a correction task to the teammate who must adjust:
"CORRECTION T4b: Update ProfilePage to use { user: { name, email } }
 instead of { profile: { username, email } }.
 Backend's response format is the source of truth."

### Step 4: Verify
After correction, verify both sides are compatible.

Priority rules in conflicts

Conflict resolution instructions for the team lead

## When Conflict is Detected

1. PAUSE execution of dependent tasks
2. ANALYZE: What exactly is inconsistent?
3. DECIDE: Who adjusts? (use priority rules)
4. ASSIGN: Correction task to the adjusting teammate
5. VERIFY: After correction, confirm compatibility
6. RESUME: Unblock dependent tasks

NEVER let a conflict pass unresolved — downstream tasks will
inherit the inconsistency and amplify it.

TeammateIdle: What to Do When an Agent Finishes First

The scenario

Task board status:
T1 [DONE] ✅ — backend-agent
T2 [IN_PROGRESS] 🔄 — backend-agent (working on endpoint)
T3 [DONE] ✅ — frontend-agent
T4 [BLOCKED] 🔒 — frontend-agent (waiting for T2)

frontend-agent is IDLE — no pending tasks available.

The frontend-agent finished its task (T3) but its next task (T4) is blocked by T2. What does the team lead do?

Strategies for TeammateIdle

1. Pre-fetch work — prepare without executing:

When a teammate is idle and all their tasks are blocked:
1. Check if there's preparatory work for blocked tasks
2. Assign a READ-ONLY pre-fetch task:
   "While waiting for T2, read the existing components in
    src/components/ and plan the structure for T4.
    Do NOT create or modify files yet."

This doesn't violate dependencies because it produces no output — it only prepares the teammate to work faster when it's unblocked.

2. Documentation tasks:

When a teammate is idle:
- Assign documentation for completed tasks
- "Document the components you created in T3:
   - Props interfaces
   - Usage examples
   - Edge cases handled"

Take advantage of the idle time for useful work that doesn't require dependencies.

3. Cross code review:

When a teammate is idle:
- Assign a review of another teammate's completed work
- "Review the API endpoints created by backend-agent in T1.
   Verify the response shapes match what you'll need in T4.
   Report any incompatibilities."

This can detect conflicts early, before the teammate starts its dependent task.

4. Wait (legitimate in some cases):

If no preparatory work is possible:
- Log: "[teammate] is idle, waiting for [dependency]"
- This is acceptable — not all idle time needs to be filled
- Don't create busywork that adds complexity without value

Idle management instructions for the team lead

## TeammateIdle Protocol

When a teammate completes all assigned tasks and has no PENDING tasks:

1. CHECK: Are there BLOCKED tasks for this teammate?
   - If yes → Can pre-fetch work be assigned? → Assign read-only task
   - If no → This teammate is DONE for this request

2. OPTIONAL PRODUCTIVE TASKS (in order of value):
   a. Review another teammate's output for compatibility
   b. Document completed work
   c. Analyze the codebase for potential issues related to the request

3. LOG: "frontend-agent idle at [timestamp]. Assigned: [task or 'waiting']"

4. RESUME: When dependency completes, immediately assign the unblocked task

RULE: Idle tasks MUST be low-effort and NEVER delay critical path.
Do not assign a 30-minute documentation task if the dependency
might complete in 5 minutes.

Team Failure Modes

Failure Mode 1: Teammate fails

T2: GET /profile → backend-agent → FAILED
Error: "Cannot create endpoint — model User doesn't exist yet"

Cause: Undetected dependency (T2 needed T1 but it wasn't declared).

The team lead's resolution:

1. Analyze: T2 failed because the User model doesn't exist
2. Diagnosis: Missing dependency — T2 should have depended on a
   model creation task
3. Action: Create T1b: "Create User model" → assign to backend-agent
4. Update: T2 now depends on T1b
5. Execute T1b, then retry T2

Failure Mode 2: Teammate loops

T3: Implement validation → backend-agent → DONE
Team lead: "Output doesn't match spec, fix these issues..."
T3: Retry → backend-agent → DONE
Team lead: "Still doesn't match, now it has different issues..."
T3: Retry again...

Cause: The team lead and the teammate have different expectations or the spec is ambiguous.

Resolution:

## Loop Detection

If a task has been retried 2+ times:
1. STOP retrying
2. Compare: original spec vs teammate output vs team lead feedback
3. Identify: Is the spec ambiguous? Is the team lead's feedback
   contradictory? Is the teammate misunderstanding?
4. If ambiguous spec → clarify and retry once more
5. If contradictory feedback → team lead acknowledges and adjusts
6. If persistent misunderstanding → escalate to user with details

MAXIMUM RETRIES: 2 per task. After that, escalate.

Failure Mode 3: Cascading failure

T1 → DONE
T2 → DONE (but output has a subtle bug)
T4 → DONE (built on T2's buggy output — inherited the bug)
T5 → FAILED (because T4's bug caused a crash)

Cause: The team lead didn't verify T2's quality before unblocking T4.

Resolution:

## Quality Gates

After each task completes, before unblocking dependents:
1. Read the teammate's output report
2. Quick verification:
   - Does the output match the task description?
   - Are files in the correct directories?
   - Does the output format match expectations?
3. If verification fails → return to teammate for fixes
4. Only unblock dependents after verification passes

For cascading failures:
1. Identify the root cause (which task introduced the bug?)
2. Fix the root cause task first
3. Re-run affected downstream tasks
4. Do NOT patch — fix at the source

Failure Mode 4: Resource contention

backend-agent: modifying src/api/router.py (adding route)
frontend-agent: reading src/api/router.py (checking endpoints)

It's not a technical conflict (one reads, the other writes), but the frontend-agent may read an incomplete state.

Resolution:

## File Access Coordination

If two teammates need the same file:
1. WRITE wins over READ — let the writer finish first
2. After write completes, reader gets the updated version
3. If both need to WRITE — this is a boundary violation.
   Only one teammate should own each file.

Preventive: Ensure boundaries don't overlap (capsule 03).

Failure Mode 5: Team lead context overflow

With multiple teammates reporting extensive results, the team lead can exceed its context window.

Resolution:

## Context Management for Team Lead

1. Instruct teammates to keep reports concise:
   "Maximum 20 lines per task report"
2. After processing a teammate's output, summarize before forwarding:
   Instead of forwarding the full report, extract key information
3. Use the progress log format, not full reports:
   "T2 DONE: Created GET /profile (src/api/routes/profile.py),
    returns ProfileResponse with 4 fields"
4. If context is getting full, the team lead should consolidate:
   Summarize all completed tasks in 1-2 lines each

Complete Pattern: Communication Protocol

Here's the complete communication protocol to include in the team lead's system prompt:

## Communication Protocol

### Outbound (team lead → teammate)
When assigning a task, ALWAYS include:
1. Task ID and clear description
2. Context from prior tasks (extracted, not raw output)
3. Files to work in
4. Expected output format
5. Dependencies to be aware of

### Inbound (teammate → team lead)
Expect from each teammate:
1. Task Report with status (DONE/PARTIAL/BLOCKED/FAILED)
2. Files created/modified
3. Key decisions made
4. Dependencies needed (if BLOCKED)
5. Errors encountered (if FAILED)

### Cross-team (teammate A needs info from teammate B)
1. Teammate A reports BLOCKED with specific question
2. Team lead checks if answer exists in prior outputs
3. If yes → forward relevant information
4. If no → create micro-task for teammate B
5. After answer → unblock teammate A with context

### Conflict (two teammates disagree)
1. Pause dependent tasks
2. Compare outputs side by side
3. Apply priority rules (data source > consumer)
4. Assign correction to the lower-priority teammate
5. Verify compatibility
6. Resume

### Failure (teammate reports error)
1. Read error report
2. Classify: recoverable or blocking
3. If recoverable → retry with additional context (max 2)
4. If blocking → escalate to user
5. Update task board: mark dependent tasks as BLOCKED

### Idle (teammate has no work)
1. Assign pre-fetch or documentation task
2. Or: assign cross-review of another teammate's work
3. Or: wait (legitimate if dependency is almost done)
4. Never assign work that delays the critical path

Manual Alternative: Messaging Without Agent Teams

Without formal Agent Teams, the coordinator manages the communication explicitly:

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

## Communication as Coordinator

### Passing context between teammates

When delegating to teammate B after teammate A completes:

"You are backend-agent. Here is your task:

TASK: T3 — Create PUT /profile endpoint
DEPENDS ON: T1 (schema — DONE)

CONTEXT FROM PRIOR TASKS:
- User model defined in src/models/user.py (from T1)
- Fields: id (int), username (str), email (str), avatar_url (str|None)
- GET /profile already exists at src/api/routes/profile.py (from T2)

DELIVERABLE: PUT endpoint that updates user profile fields.
Report: files modified, response format, validation rules."

### Resolving conflicts manually

If two teammates produce incompatible outputs:

1. Read both outputs fully
2. Identify the specific incompatibility
3. Decide which teammate adjusts (backend is source of truth for API)
4. Delegate a correction task with explicit instructions:
   "CORRECTION: The ProfilePage uses { profile: { username } } but
    the API returns { user: { name } }. Update ProfilePage to match
    the API response format: { user: { name, email } }."

The difference: without Agent Teams, all of this is manual in the delegation prompt. With Agent Teams, the team lead has established protocols. The result is similar for small teams, but the manual alternative requires more detailed prompts.

Troubleshooting

"The teammates don't receive context from prior tasks"

Cause: The team lead delegates without including outputs from previous tasks.

Solution: Add an emphatic rule:

MANDATORY: When assigning a task that has dependencies,
ALWAYS include relevant outputs from completed dependencies.

For each dependency:
- What was the task?
- What files were created/modified?
- What data formats were defined?
- What decisions were made?

Without this context, the teammate will make incompatible decisions.

"The conflicts are detected too late"

Cause: The team lead doesn't verify compatibility between outputs.

Solution: Add a quality gate after each task:

After EACH task completion:
1. Read the output
2. Compare with outputs of related tasks (same resource, same files)
3. If incompatibility found → resolve BEFORE assigning next task
4. Log: "Compatibility check: T[x] output is compatible with T[y]"

"A teammate is idle indefinitely"

Cause: Its only pending task has a dependency that's failing or taking a long time.

Solution: Add a timeout and escalation:

If a teammate has been idle for more than 3 task completions
by other teammates:
1. Check why the blocking dependency is not done
2. If the blocker is IN_PROGRESS → wait
3. If the blocker is FAILED → resolve or escalate
4. Consider: can the idle teammate help unblock?
   (e.g., frontend-agent reviews API design to speed up backend)

"The team lead loses track of the team's state"

Cause: Too many tasks and communications without a log.

Solution: Add a mandatory status display:

After EVERY action (assign, complete, fail, conflict):
Display the current state:

📋 Team Status
- frontend-agent: [IDLE | WORKING on T4 | BLOCKED]
- backend-agent: [IDLE | WORKING on T2 | BLOCKED]

Task Board:
T1 [DONE] ✅  T2 [PROGRESS] 🔄  T3 [BLOCKED] 🔒
T4 [PENDING] ⏳  T5 [BLOCKED] 🔒

"The teammates generate reports too long that saturate the context"

Cause: No size limit on the Task Reports.

Solution: Add an explicit restriction to each teammate's output format:

## Output Constraints
- Task Report: maximum 20 lines
- List only files created/modified (not full content)
- Summary in 1-2 sentences
- Detailed code belongs in the files, not in the report

Exercises

Exercise 1: Design a context message (Easy)

The backend-agent completed T2 (GET /users endpoint). Now the team lead must assign T4 (UserList component) to the frontend-agent. Write the assignment message including the context extracted from T2's output.

## Task Assignment for frontend-agent

**Task:** T4 — Implement UserList component
**Depends on:** T2 (GET /users — DONE ✅)

### Context from T2 (backend-agent):
- Endpoint: GET /api/users
- Response format:
  ```json
  {
    "users": [
      { "id": 1, "name": "Alice", "email": "alice@example.com", "role": "admin" }
    ],
    "total": 42,
    "page": 1,
    "per_page": 20
  }

</details>

### Exercise 2: Resolve a conflict (Easy)

The backend-agent created `POST /api/users` that returns `{ "user_id": 123, "status": "created" }`. The frontend-agent created the form expecting the response `{ "id": 123, "message": "User created" }`. Write the team lead's resolution.

<details>
<summary>See solution</summary>

```markdown
## Conflict Resolution

### Incompatibility detected:
- Backend response: { "user_id": 123, "status": "created" }
- Frontend expects: { "id": 123, "message": "User created" }
- Differences: user_id vs id, status vs message

### Decision:
Backend is source of truth for API responses.
Frontend must adjust to match the actual API response.

### Correction task for frontend-agent:
"CORRECTION T3b: Update the registration form's success handler.

The POST /api/users endpoint returns:
  { "user_id": 123, "status": "created" }

NOT { "id": 123, "message": "User created" } as you implemented.

Update:
1. Change response parsing to use user_id instead of id
2. Change success message to use status instead of message
3. Verify the form works with the actual API response format"

### Verification:
After correction, confirm frontend uses user_id and status fields.

Exercise 3: Idle management protocol (Medium)

The team has 3 teammates. frontend-agent finished T3 and its next task T6 depends on T4 (backend-agent, IN_PROGRESS) and T5 (db-dev, DONE). Design 3 productive options for the idle frontend-agent and recommend one.

"Read the output of T5 (db-dev) and prepare for T6.
 Analyze the data model created in T5. Plan the component
 structure for T6 but do NOT create files yet."

"Review the data types created by db-dev in T5.
 Verify the TypeScript interfaces match what you'll
 need for T6. Report any incompatibilities."

"Document the components you created in T3:
 - Props interfaces with descriptions
 - Usage examples
 - Edge cases handled"

Exercise 4: Manage a cascading failure (Medium)

T1 (DONE) → T2 (DONE, with a subtle bug) → T4 (DONE, inherits the bug) → T5 (FAILED because the bug caused a crash). Write the team lead's resolution plan step by step.

## Cascading Failure Resolution Plan

### Step 1: Identify root cause
T5 failed with a crash. Read T5's error report.
Error points to data from T4. Read T4's output.
T4 used data from T2. Read T2's output.
Root cause: T2 produced a field with the wrong type
(string instead of int for user_id).

### Step 2: Fix at the source
Assign a correction to the teammate who did T2:
"CORRECTION T2b: Fix user_id type in ProfileResponse.
 Current: user_id: str (incorrect)
 Expected: user_id: int
 File: src/api/schemas/profile.py"

### Step 3: Re-run affected downstream
After T2b completes:
- T4 must be re-run (it consumed T2's output)
  "RE-RUN T4b: Rebuild ProfilePage using corrected T2b output.
   user_id is now int, not str."
- T5 must be re-run after T4b
  "RE-RUN T5b: Retry ProfileForm with corrected data from T4b."

### Step 4: Verify the fix propagated
After all re-runs:
- Verify T2b: user_id is int ✅
- Verify T4b: component uses int user_id ✅
- Verify T5b: form works without crash ✅

### Step 5: Post-mortem
"Root cause: T2 had a type error (user_id: str instead of int).
 Impact: 3 tasks affected (T2, T4, T5).
 Prevention: Added type verification to the quality gate."

### Lesson: Quality gates after each task would have
caught this at T2, preventing the cascade.

Exercise 5: Complete communication protocol (Hard)

Write a communication protocol for a team of 3 teammates (ui-dev, api-dev, db-dev) working on an e-commerce app. Include: outbound format, inbound format, conflict rules with 3 specific scenarios, idle strategy, and failure escalation.

## E-commerce Team Communication Protocol

### Outbound (team lead → teammate)
Format:
"TASK: [ID] — [description]
 AGENT: [teammate name]
 DEPENDS: [task IDs or 'none']
 CONTEXT: [extracted data from dependencies]
 FILES: [specific paths to create/modify]
 DELIVER: [expected output]"

### Inbound (teammate → team lead)
Expected format:
"TASK: [ID]
 STATUS: DONE | PARTIAL | BLOCKED | FAILED
 FILES: [created/modified list]
 OUTPUT: [key data: schemas, endpoints, components]
 NOTES: [decisions, questions, blockers]"

### Conflict Rules

Scenario 1: Product schema disagreement
- db-dev defines Product with price: Decimal
- api-dev serializes price as float
- Resolution: db-dev wins (data integrity). api-dev converts
  Decimal to string in the API response to preserve precision.

Scenario 2: Cart endpoint ownership
- api-dev created POST /cart in routes/cart.py
- ui-dev created a mock POST /cart in the frontend mock server
- Resolution: api-dev owns real endpoints. ui-dev uses api-dev's
  endpoint. Delete the frontend mock.

Scenario 3: Naming inconsistency
- db-dev: product_category (snake_case in DB)
- api-dev: productCategory (camelCase in API)
- ui-dev: ProductCategory (PascalCase in React)
- Resolution: Each layer uses its convention. The API serializer
  translates between DB snake_case and JSON camelCase.

### Idle Strategy
Priority order:
1. Cross-review of related teammate's output
2. Pre-fetch for blocked task
3. Write tests for completed work (if test-capable)
4. Wait (if dependency is almost done)

### Failure Escalation
- 1st failure → retry with context
- 2nd failure → different approach or additional context
- 3rd failure → escalate to user with full report
- NEVER retry more than 2 times for the same task

Exercise 6: Simulate a team lead session (Hard)

Without running Claude Code, simulate on paper (or in a doc) a complete team lead session with 2 teammates and 5 tasks. For each step, write: what the team lead would do, what it would delegate, what it would receive, and how it would update the task board. Include at least one conflict and one idle case.

## Simulation: User Profile Feature

Team: team-lead, frontend-agent, backend-agent
Request: "Implement user profile page with edit capability"

### Step 1: Generate task board
Team lead generates:
| ID | Task | Agent | Depends | Status |
| T1 | User schema | backend | none | PENDING |
| T2 | GET /profile | backend | T1 | BLOCKED |
| T3 | PUT /profile | backend | T1 | BLOCKED |
| T4 | ProfilePage | frontend | T2 | BLOCKED |
| T5 | EditForm | frontend | T3, T4 | BLOCKED |

### Step 2: Assign T1
Team lead: "T1 to backend-agent: Create User Pydantic schema"
frontend-agent: IDLE (no pending tasks)
Team lead idle action: "frontend-agent, review existing components
 for patterns we should follow in T4/T5"

### Step 3: T1 completes
backend-agent: "DONE. UserSchema in src/schemas/user.py"
Team lead: Unblocks T2, T3 → both PENDING
Assigns T2 to backend-agent (HIGH priority)
Assigns... T3 also to backend-agent. But backend is busy with T2.
→ T3 stays PENDING until T2 is done.
frontend-agent: Still IDLE. Team lead: "pre-fetch for T4"

### Step 4: T2 completes
backend-agent: "DONE. GET /profile returns { name, email, bio }"
Team lead: Unblocks T4 → PENDING
Assigns T3 to backend-agent
Assigns T4 to frontend-agent WITH context from T2

### Step 5: CONFLICT
T3 completes: backend "PUT /profile accepts { name, email }"
T4 completes: frontend "ProfilePage shows name, email, AND bio"
Conflict: PUT doesn't accept bio but the frontend shows it.
Team lead: "Backend is source of truth. frontend-agent, note that
 bio is read-only (not editable). Adjust T5 to exclude bio from the form."

### Step 6: T5 assigned with correction
Team lead: "T5 to frontend-agent: EditForm for name and email ONLY.
 Bio is displayed in T4 but not editable."
Result: T5 DONE.

### Step 7: Final
Team lead: All tasks DONE. Final report.

Summary

• The teammates don't communicate directly — all communication passes through the team lead as an intermediary
• There are 3 types of communication: output forwarding (passing results), query (requesting information), and notification (informing of changes)
• Conflicts are resolved with priority rules: the data source wins over the consumer, CLAUDE.md wins over individual preferences
• TeammateIdle is handled with productive tasks: pre-fetch, cross-review, or documentation — but never work that delays the critical path
• The 5 main failure modes: teammate fails, teammate loops, cascading failure, resource contention, and context overflow
• Quality gates after each task prevent cascading failures — verify before unblocking
• The communication protocol (outbound, inbound, cross-team, conflict, failure, idle) is the contract that makes the team predictable
• Without Agent Teams, all this communication is managed manually in the coordinator's delegation prompts

Additional Resources

1. Create Custom Subagents (Anthropic Docs) — Official documentation of subagents and communication
2. Claude Code Best Practices — Delegation and coordination best practices
3. Multi-Agent Orchestration — Multi-agent coordination patterns
4. Prompt Engineering: Be Clear and Direct — Clarity in communication between agents
5. Claude Code CLI Reference — CLI reference for foreground/background
6. Claude Code Settings — Context management configuration
7. Conflict Resolution in Distributed Systems — Theoretical foundations of conflict resolution
8. Claude Code Overview — General context of Claude Code

Next capsule: In capsule 06 you'll build the module's project: a functional team of 3 agents (team lead + frontend-agent + backend-agent) with a task board of 5+ tasks and real dependencies. You'll integrate everything learned in capsules 02-05: team lead configuration, teammate definition with boundaries, task board with dependencies, and communication and conflict resolution protocols.