## Example 1: Bug Fix — Selective Context

**Request:** "Fix the bug where users can't update their email address."

**Bad Context (The Dump):**
```
Here are all the files in the project:

src/api/users.ts (200 lines)
src/api/auth.ts (150 lines)
src/api/orders.ts (180 lines)
src/models/user.ts (80 lines)
src/models/order.ts (60 lines)
src/utils/errors.ts (40 lines)
src/utils/email.ts (90 lines)
src/middleware/validate.ts (70 lines)
src/middleware/auth.ts (60 lines)
tests/users.test.ts (300 lines)
tests/auth.test.ts (200 lines)
package.json
tsconfig.json
.env

Fix the bug where users can't update their email address.
```

**Good Context (Context Engineering):**
```
## Task
Fix the bug where users cannot update their email address.

## Current State
The update endpoint returns 400 with: "Email already in use"

Relevant code — src/api/users.ts lines 45-62:
```typescript
export async function updateUser(req: Request, res: Response) {
  const { id } = req.params;
  const { email, name } = req.body;
  
  // Bug is here — this check runs even when email is not being changed
  const existingUser = await User.findOne({ email });
  if (existingUser && existingUser.id !== id) {
    return res.status(400).json({ error: "Email already in use" });
  }
  
  const user = await User.update(id, { email, name });
  return res.json({ data: user });
}
```

## Requirements
- Fix should only check for email conflicts when email is actually being changed
- Preserve the existing check for new email conflicts
- Do not change the API response format

## Relevant Context
The User model (src/models/user.ts) has a unique constraint on email.
The test file (tests/users.test.ts line 145) has a test case for email updates.
```

**Why This Works:**
- Includes only the relevant function with line numbers
- Shows the exact error message
- Explains what the bug is (check runs when email not changed)
- Lists clear requirements
- References other files without dumping them

---

## Example 2: Feature Implementation — Progressive Disclosure

**Request:** "Add a notification system that sends emails when orders are shipped."

**Turn 1: Exploration Context**
```
## Task
Plan a notification system for order shipping emails.

## Current State
Project structure:
- src/api/ — API endpoints (express + typescript)
- src/models/ — Data models (prisma ORM)
- src/services/ — Business logic
- src/utils/ — Shared utilities

Relevant files:
- src/services/order.ts — Order status management
- src/utils/email.ts — Existing email utility (send, templates)
- src/models/user.ts — User model (has email field)

No existing notification system.

## Requirements
- Send email when order status changes to "shipped"
- Use existing email utility
- Support template for shipping notification
- Include order details in email

## What I need from you
List the files to create/modify and the implementation approach.
```

**Turn 2: Implementation Context**
```
## Task
Implement the notification system based on the plan from Turn 1.

## Plan (from Turn 1)
1. Create src/services/notification.ts — NotificationService class
2. Modify src/services/order.ts — Call notification on status change
3. Create email template for shipping notifications
4. Add tests for notification service

## Current State — Files to Modify
src/services/order.ts lines 28-45:
```typescript
export async function updateOrderStatus(
  orderId: string, 
  status: OrderStatus
): Promise<Order> {
  const order = await prisma.order.update({
    where: { id: orderId },
    data: { status, updatedAt: new Date() }
  });
  // No notification logic exists yet
  return order;
}
```

src/utils/email.ts — Existing email utility:
```typescript
export async function sendEmail(
  to: string, 
  template: string, 
  data: Record<string, any>
): Promise<void> { ... }
```

## Requirements
- NotificationService.sendShippingNotification(order, user)
- Call from updateOrderStatus when status === 'shipped'
- Email template: order-shipped
- Include: order ID, items, estimated delivery

## Output
Provide the complete implementation for all files.
```

**Why This Works:**
- Turn 1 focuses on planning — includes structure and requirements
- Turn 2 carries forward the plan and includes specific code to modify
- Each turn includes only what is needed for that step
- Context grows with the task complexity

---

## Example 3: Code Review — Structured Context

**Request:** "Review this pull request for security issues."

**Bad Context:**
```
Review this PR: [paste entire diff of 500 lines]
```

**Good Context:**
```
## Task
Security review of PR #247: Add user profile endpoints.

## PR Summary
Adds GET/PUT endpoints for user profiles with image upload.

## Files Changed (5 files, +280 lines)
- src/api/profile.ts (new, 95 lines) — Profile CRUD endpoints
- src/services/upload.ts (new, 65 lines) — Image upload handling
- src/models/user.ts (+15 lines) — Added profile fields
- src/middleware/auth.ts (+10 lines) — Updated auth middleware
- tests/profile.test.ts (new, 95 lines) — Tests

## Security-Relevant Changes
1. src/api/profile.ts lines 30-55: File upload endpoint
2. src/services/upload.ts lines 12-35: File validation
3. src/middleware/auth.ts line 8: New permission check

## Specific Concerns
- File upload: Is the file type validated? Size limits?
- Image processing: Is there server-side resizing (prevent large file DoS)?
- Authorization: Can users access other users' profiles?
- Input sanitization: Are profile fields sanitized?

## What to Review
Focus on security issues only. Do not review style or performance.
```

**Why This Works:**
- Summary gives context without reading the entire diff
- Lists specific files and line ranges for security-relevant code
- States specific concerns to investigate
- Clear scope: security only, not style/performance