> ## Documentation Index
> Fetch the complete documentation index at: https://docs.enagrams.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Work Packages

> Scoped units of work generated from meetings that agents pick up automatically

## What Is a Work Package?

A work package is a unit of work created from a meeting. It specifies:

* What to build (`title` + `description`)
* Why (`decisions` — the meeting decisions that motivated it)
* Which files to touch (`files`, and when resolvable, symbol IDs)
* Who should do it (`assignee`)

Work packages are generated with non-overlapping file/symbol sets within the same workspace so two agents claiming two packages never step on each other.

## Work Packages vs Tasks

|             | Work package                         | [Task](/concepts/tasks)                                           |
| ----------- | ------------------------------------ | ----------------------------------------------------------------- |
| Origin      | Extracted from a meeting ingestion   | Created live during a workstream                                  |
| Granularity | Coarse (often several hours of work) | Fine (single follow-up inside a workstream)                       |
| Who assigns | Picked up by humans in the dashboard | Delegated by agents via [`delegate_task`](/mcp/delegate-task)     |
| Gate-aware  | No                                   | Yes — atomic completion via [`confirm_ready`](/mcp/confirm-ready) |

Work packages are the "top of funnel" — once claimed, an agent typically starts or joins a [workstream](/concepts/workstreams) and the detailed follow-up work is tracked there as tasks.

## Lifecycle

```
Open → Claimed → In Progress → Completed
```

| Status        | Description                     |
| ------------- | ------------------------------- |
| `open`        | Available for anyone to claim   |
| `claimed`     | Assigned to a developer         |
| `in_progress` | Agent is actively working on it |
| `completed`   | Done                            |

## Claiming a Package

<Tabs>
  <Tab title="Dashboard">
    1. Go to **Dashboard → Work Packages**
    2. Find an `open` package
    3. Click **Claim**
  </Tab>

  <Tab title="API">
    ```bash theme={null}
    POST /workspaces/:id/packages/:pid/claim
    Authorization: Bearer ek_...
    ```
  </Tab>
</Tabs>

## Receiving Packages in `sync`

Claimed packages are included in [`sync`](/mcp/sync) responses automatically:

```json theme={null}
{
  "your_work": [
    {
      "id": "pkg_abc",
      "title": "Build user registration endpoint",
      "description": "Create POST /users/register with Zod validation and password hashing",
      "files": [
        "src/users/register.ts",
        "src/users/validate.ts",
        "src/auth/password.ts"
      ],
      "decisions": [
        { "title": "Use Zod for validation", "rationale": "Type-safe, TypeScript-native" },
        { "title": "Use bcrypt for password hashing", "rationale": "Industry standard, adaptive cost" }
      ],
      "status": "claimed"
    }
  ]
}
```

The agent sees exactly what to build, the relevant architectural decisions, and which files are in scope — without any additional prompting.

## Updating Status

```bash theme={null}
PATCH /workspaces/:id/packages/:pid/status
Authorization: Bearer ek_...

{ "status": "in_progress" }
```

Or, more commonly, the agent starts a [workstream](/concepts/workstreams) for the package and tracks detailed progress with [tasks](/concepts/tasks).

## Non-overlapping File Sets

When Enagrams generates packages from a meeting, a second LLM pass divides the work into non-overlapping file sets:

* Package A: `src/auth/login.ts`, `src/auth/middleware.ts`
* Package B: `src/users/register.ts`, `src/users/validate.ts`

Two agents claiming these can work in parallel without file conflicts. For work that can't be cleanly split, create a single workstream and use [tasks](/concepts/tasks) + [negotiation](/concepts/negotiation) to divide the work dynamically.

## Viewing Packages

**Dashboard → Work Packages** shows a kanban board organized by status, with:

* Who owns each package
* Which files (and symbols) are covered
* The originating meeting
* Any current [reservations](/concepts/file-locking) covering those files