Pack Structure & Priority

Learn about the pack content contract, section markers, export levels, and how ADE assembles the context priority stack for agent sessions.

Pack Content Contract

Packs use a stable, machine-readable format that agents can parse reliably across regenerations.

Header

Every pack begins with a metadata header:

<!-- ade:pack type=lane id=lane-abc123 generated=2026-03-12T09:14:00Z version=3 -->

Section Markers

Content is divided into named sections with stable markers:

<!-- section: intent -->
This lane is implementing the user authentication refresh flow...

<!-- section: criteria -->
- All existing auth tests must pass
- New refresh token endpoint must be covered by integration tests
- No changes to the public API surface

<!-- section: touched-files -->
- src/auth/refreshToken.ts (modified)
- src/auth/refreshToken.test.ts (created)
- src/api/routes/auth.ts (modified)

<!-- section: diff-summary -->
Added `refreshToken()` function. Extended `/auth/refresh` route handler...

Agents can rely on these section names being stable. ADE never renames or removes a section marker without a major version bump.

Export Levels

When exporting or sharing a pack, three verbosity levels are available:

Level	Contents	Use Case
Lite	Header + intent section only	Quick orientation, small context windows
Standard	All primary sections (intent, criteria, touched files, diff summary)	Normal agent sessions
Deep	Full pack including history entries and extended annotations	Deep debugging, mission planning

---

Context Priority and Injection

When an agent session begins, ADE assembles the context stack in priority order. More specific context always takes precedence over general context.

1. Lane Pack (Highest Priority)

   The lane’s own pack is always included first. It defines the specific work context the agent is operating in.

2. Feature Pack (If Applicable)

   If the lane is linked to a Linear issue, the Feature Pack for that issue is included. This brings in cross-lane awareness and the original issue requirements.

3. Project Pack (Base Layer)

   The Project Pack is always included as the foundational context layer. Every agent gets the project-wide architecture and conventions.

4. Conflict Pack (If Active Conflicts)

   If the lane has active merge conflicts, the relevant Conflict Pack is included. The agent sees both sides of the conflict and the suggested resolution.

5. External MCP Tool Results

   Dynamic context fetched from MCP tools during the session (e.g., a Linear issue’s current state, a GitHub PR’s latest review comments). This is fetched live, not from pack files.

The context stack is assembled at session start and does not update mid-session (except for MCP tool results, which are fetched on demand). If the lane pack was updated while a session was running, the agent will use the version from session start. Start a new chat session to pick up a refreshed pack.

---

Accessing Packs Manually

Packs are plain Markdown files. You can read them directly from the filesystem, open them in your editor, or copy their contents for use outside ADE.

From the Context View

Open the Context tab in ADE’s left sidebar. The pack tree shows all packs with their type, associated lane/feature/mission, freshness status, and a preview of the intent section.

Click any pack entry to open the full pack in ADE’s built-in viewer. Use the Export button to save a copy to your clipboard or a file.

From the Filesystem

Packs are stored as .md files in .ade/artifacts/packs/. Open them directly in your editor:

# View the current project pack
cat .ade/artifacts/packs/project/current.md

# View a specific lane's pack
cat ".ade/artifacts/packs/lanes/<lane-id>/current.md"

Via MCP Tools

If you have an ADE-connected AI agent (via Cursor, Claude Desktop, etc.), you can call the ade_get_pack MCP tool:

{
  "tool": "ade_get_pack",
  "params": {
    "type": "lane",
    "id": "lane-abc123",
    "exportLevel": "standard"
  }
}