home / skills / outfitter-dev / agents / context-management

This skill helps you manage long-running tasks and preserve state across context compaction by using persistent Task operations and delegated exploration.

npx playbooks add skill outfitter-dev/agents --skill context-management

Review the files below or copy the command above to add this skill to your agents.

Files (4)
SKILL.md
10.2 KB
---
name: context-management
description: Manage context window, survive compaction, persist state. Use when planning long tasks, coordinating agents, approaching context limits, or when "context", "compaction", "tasks", or "persist state" are mentioned.
user-invocable: false
metadata:
  version: "1.0.0"
  related-skills:
    - subagents
    - pathfinding
---

# Context Management

Manage your context window, survive compaction, persist state across turns.

<when_to_use>

- Planning long-running or multi-step tasks
- Coordinating multiple subagents
- Approaching context limits (degraded responses, repetition)
- Need to preserve state across compaction or sessions
- Orchestrating complex workflows with handoffs

NOT for: simple single-turn tasks, quick Q&A, tasks completing in one response

</when_to_use>

<problem>

Claude Code operates in a ~128K token context window that compacts automatically as it fills. When compaction happens:

**What survives**:
- Task state (full task list persists)
- Tool results (summarized)
- User messages (recent ones)
- System instructions

**What disappears**:
- Your reasoning and analysis
- Intermediate exploration results
- File contents you read (unless in tool results)
- Decisions you made but didn't record

**The consequence**: Without explicit state management, you "wake up" after compaction with amnesia — you know what to do, but not what you've done or decided.

</problem>

<tasks>

## Tasks: Your Survivable State

Tasks are not just a tracker — they're your **persistent memory layer**. Use TaskCreate, TaskUpdate, TaskList, and TaskGet to manage state that survives compaction.

### What Goes in Tasks

| Category | Example |
|----------|---------|
| Current work | `Implementing auth refresh flow` (status: in_progress) |
| Completed work | `JWT validation logic added to middleware` (status: completed) |
| Discovered work | `Handle token expiry edge case` (status: pending) |
| Key decisions | Embed in task description: "Using RS256 per security review" |
| Agent handoffs | `[reviewer] Review auth implementation` + metadata: `{agentId: "abc123"}` |
| Blockers | Create blocker task, use `blockedBy` field |

### Task Discipline

**Exactly one `in_progress`** at any time. Call `TaskUpdate` to mark `in_progress` before starting.

**Mark complete immediately**. Don't batch completions — `TaskUpdate` with `completed` as you finish.

**Include agent IDs** for resumable sessions in task metadata.

**Expand dynamically**. `TaskCreate` as you discover work; don't front-load everything.

**Action-oriented subjects**. Use verbs: "Implement X", "Fix Y", "Review Z"

### Status Flow

```
pending → in_progress → completed
                ↓
         (blocked → TaskCreate for blocker, add blockedBy)
```

If blocked, don't mark complete. Create a new task for the blocker and link with `addBlockedBy`.

### Pre-Compaction Pattern

As context fills, ensure tasks capture progress. Use TaskUpdate to add details to in_progress task description:

```
Task: Implementing token refresh
Description:
  - Refresh endpoint: POST /api/auth/refresh
  - Token rotation: enabled
  - Refresh window: 5 minutes before expiry
  - Remaining: validation logic
```

Decisions embedded in completed task descriptions. Current state detailed in active task. Future work queued as pending.

</tasks>

<pre_compaction>

## Pre-Compaction Checklist

Run through this when context is filling (you'll notice: slower responses, repetition, degraded reasoning):

1. **Capture progress** — What's done? `TaskUpdate` completed tasks with outcomes in description.

2. **Record decisions** — What did you decide? Why? Put in task descriptions.

3. **Note current state** — Where exactly are you in the current task? `TaskUpdate` the `in_progress` task with specifics.

4. **Queue discovered work** — What did you find that needs doing? `TaskCreate` as pending.

5. **Mark dependencies** — What needs what? Use `addBlockedBy` in `TaskUpdate`.

6. **Include agent IDs** — Any background agents? Record IDs in task metadata.

### Example: Before Compaction

**Bad** (state will be lost):

```
- [x] Research auth approaches
- [ ] Implement auth
- [ ] Test auth
```

**Good** (state survives):

```
- [x] Research auth approaches → middleware + JWT (see src/auth/README.md)
- [ ] [in_progress] Implement JWT refresh flow
    - Using jose library (already in deps)
    - Endpoint: POST /api/auth/refresh
    - Handler started in src/auth/refresh.ts:15
    - Remaining: validation logic, token rotation
- [ ] Add refresh flow tests (after impl)
- [ ] [reviewer] Security review auth module (after tests)
```

</pre_compaction>

<delegation>

## Delegation for Context Preservation

Main conversation context is precious. Every file you read, every search result, every intermediate thought consumes tokens. Subagents run in isolated contexts — only their final output returns.

### Default Stance

If a task can be delegated, delegate it.

### Delegation Decision Tree

```
Task arrives
├── Exploration/research? → Explore agent (always)
├── Multi-file reading? → Subagent (summarizes for you)
├── Independent subtask? → Background agent
├── Specialized expertise? → Domain agent (reviewer, tester, etc.)
└── Simple, focused, single-file? → Main agent (maybe)
```

> **Note**: Plugin agents require the `plugin:agent-name` format (e.g., `outfitter:reviewer`). Built-in agents (`Explore`, `Plan`, `general-purpose`) work without prefix. Use `/agents` to see available agents.

### Context-Saving Patterns

**Research delegation** — Instead of reading 10 files:

```json
{
  "description": "Find auth implementation",
  "prompt": "Locate authentication-related files, summarize the auth flow",
  "subagent_type": "Explore"
}
```

Main agent receives: concise summary, not 10 file contents.

**Parallel review** — Instead of sequential analysis:

```json
// Single message, multiple calls, all run_in_background: true
{ "subagent_type": "outfitter:reviewer", "run_in_background": true, "prompt": "Security review..." }
{ "subagent_type": "outfitter:analyst", "run_in_background": true, "prompt": "Performance review..." }
```

Main agent: stays lean, collects results when ready.

**Background execution** — For independent work:

```json
{
  "subagent_type": "outfitter:tester",
  "run_in_background": true,
  "prompt": "Run integration tests for auth module"
}
```

Continue other work; retrieve with `TaskOutput` later.

### Task Integration

Track delegated work in tasks:

```
[analyst] Research caching strategies (pending, metadata: {taskId: "def456"})
[engineer] Implement cache layer (pending, blockedBy: analyst task)
[reviewer] Review cache implementation (pending, blockedBy: engineer task)
[tester] Validate cache behavior (pending, blockedBy: reviewer task)
```

When background agents complete, `TaskUpdate` status and process results.

### What NOT to Delegate

- Direct user Q&A needing conversation history
- Simple edits to files already in context
- Final synthesis requiring your judgment

</delegation>

<cross_session>

## Cross-Session Patterns

For work spanning multiple sessions, use episodic memory MCP server.

> **Prerequisites**: Cross-session patterns require an episodic-memory MCP server to be configured. If unavailable, skip this section — Tasks handle single-session persistence.

### Saving State

At session end or before long pause:

```json
{
  "tool": "episodic-memory:save",
  "content": {
    "task": "Implementing auth refresh flow",
    "status": "in_progress",
    "completed": ["JWT validation", "Refresh endpoint structure"],
    "remaining": ["Token rotation logic", "Tests", "Security review"],
    "decisions": {
      "library": "jose",
      "algorithm": "RS256",
      "refresh_window": "5 minutes"
    },
    "files_modified": ["src/auth/refresh.ts", "src/auth/middleware.ts"],
    "next_steps": "Implement token rotation in refresh.ts:42"
  }
}
```

### Restoring State

At session start:

```json
{
  "tool": "episodic-memory:search",
  "query": "auth refresh implementation"
}
```

Then reconstruct tasks from saved state using `TaskCreate`.

### When to Use Cross-Session

- Multi-day projects
- Complex refactors with many steps
- Work that will be interrupted
- Handing off to future sessions

For single-session work, Tasks alone suffice.

</cross_session>

<workflow>

## Workflow Integration

### At Task Start

1. `TaskCreate` with initial scope
2. If complex: use Plan subagent to explore, preserve main context
3. `TaskUpdate` first task to `in_progress`

### During Execution

1. `TaskUpdate` as work progresses
2. Delegate exploration to subagents
3. Mark completed immediately (no batching)
4. `TaskCreate` for discovered work
5. Note decisions in completed task descriptions

### Approaching Compaction

1. Run pre-compaction checklist
2. Ensure current state captured in `in_progress` task description
3. Record any background agent IDs in task metadata

### After Compaction

1. `TaskList` to read task state (it persists)
2. Resume from `in_progress` task
3. Use saved details to continue without re-exploration

### At Task Completion

1. `TaskUpdate` final tasks to complete with outcomes in description
2. If multi-session: save to episodic memory
3. Report summary to user

</workflow>

<rules>

ALWAYS:
- Use Tasks for any work over 2-3 steps
- `TaskUpdate` before significant actions
- Mark completed immediately, not batched
- Include agent IDs in task metadata for resumable sessions
- Delegate exploration to subagents (preserves main context)
- Record decisions in completed task descriptions
- Run pre-compaction checklist when context fills

NEVER:
- Rely on conversation history surviving compaction
- Keep large research results in main context (delegate or summarize)
- Have multiple `in_progress` tasks simultaneously
- Stop early due to context concerns (persist state instead)
- Batch multiple completions together
- Leave tasks vague ("do the thing" → "Implement refresh endpoint")

</rules>

<references>

- [task-patterns.md](references/task-patterns.md) — deep patterns and templates
- [delegation-patterns.md](references/delegation-patterns.md) — context-preserving delegation
- [cross-session.md](references/cross-session.md) — episodic memory integration
- subagents skill — agent orchestration patterns

</references>

Overview

This skill helps manage the context window, survive automatic compaction, and persist actionable state across turns and sessions. It provides disciplined task-based state management, delegation patterns, and pre-compaction checklists so agents can resume work without losing progress or decisions.

How this skill works

The skill treats Tasks as the persistent memory layer: create, update, list, and get tasks to record progress, decisions, blockers, and agent handoffs that survive compaction. It recommends delegating heavy exploration or file-reading to subagents so the main context stays small, and offers patterns for saving/restoring cross-session state via an episodic memory tool when available.

When to use it

  • Planning long-running or multi-step tasks that need resumability
  • Coordinating multiple subagents or parallel workstreams
  • Approaching context limits (slower responses, repetition, degraded reasoning)
  • When you must preserve decisions, intermediate state, or handoffs through compaction
  • Orchestrating workflows that will be interrupted or handed off

Best practices

  • Use Tasks for any work over 2–3 steps and call TaskUpdate before significant actions
  • Keep exactly one task marked in_progress at a time and mark tasks completed immediately
  • Embed key decisions and outcomes in task descriptions so they survive compaction
  • Delegate exploration and heavy file reading to subagents; record their IDs in task metadata
  • Run the pre-compaction checklist when you see degraded responses or repetition
  • Create blocker tasks and link them with blockedBy rather than marking progress incorrectly

Example use cases

  • Implementing a token refresh flow: record current progress, decisions (library/algorithms), remaining work, and file pointers in the in_progress task
  • Coordinating a cross-team review: create reviewer tasks with agentId metadata and link dependencies via blockedBy
  • Running parallel audits: dispatch background agents for security and performance reviews and record outputs as task updates
  • Recovering after compaction: use TaskList/TaskGet to find the in_progress task and continue from recorded details
  • Saving multi-day work: persist full task state to episodic memory before pausing and restore on resume

FAQ

What survives automatic compaction?

Task state, summarized tool results, recent user messages, and system instructions persist; internal reasoning, intermediate exploration, and raw file contents do not.

How do I preserve work across sessions?

Use Tasks for session persistence and, if available, save full state to an episodic memory MCP server at pause and restore it on restart.