<system-reminder>
As you answer the user's questions, you can use the following context:
# claudeMd
Codebase and user instructions are shown below. Be sure to adhere to these instructions. IMPORTANT: These instructions OVERRIDE any default behavior and you MUST follow them exactly as written.

Contents of /Users/psulin/.claude/CLAUDE.md (user's private global instructions for all projects):

## Rules
 - Respond concisely, correctly and accurately
 - Always add and commit files after completing a task

## Documentation Standards

### README Requirements
- Write for engineers: explain what code actually does with real CLI examples and command outputs
- No marketing fluff - if claiming functionality (e.g. "quality scoring"), explain the implementation method
- Use "Modules" section instead of "Features" to avoid redundancy with core modules listing
- Include concrete dependencies, installation steps, and actual usage examples

## Code Implementation Standards

### ABSOLUTE PROHIBITION - NO EXCEPTIONS:
🚫 **NEVER CREATE:**
- Mocks (fake objects pretending to be real)
- Stubs (hardcoded return values)
- Placeholders (temporary "TODO" implementations)
- Fallbacks (return fake data when real implementation fails)

✅ **ALWAYS DO INSTEAD:**
- Implement the real thing OR
- Fail explicitly with clear error message
- If you cannot implement, say so - DO NOT FAKE IT

### Implementation Rules:
- Research and implement the single correct solution - no fallback logic or defensive patterns
- Answer questions directly without assumptions or premature implementation
- Icons only for red X's and green checkmarks - no other icons in docs or logs
- Lean Test Strategy: Golden Master snapshots, integration workflows, unit tests only for pure functions

### Examples of VIOLATIONS (NEVER DO THIS):
```python
# ❌ WRONG - Stub/Mock/Placeholder
def _call_llm(self, prompt):
    return "def example(): return 42"  # Fake placeholder

# ✅ CORRECT - Real implementation or explicit failure
def _call_llm(self, prompt):
    raise NotImplementedError("LLM integration not yet implemented")
```

Contents of /Users/psulin/organon/CLAUDE.md (project instructions, checked into the codebase):

# Organon - Agent Instructions

## Navigation Protocol

**CRITICAL:** This is your primary guide for finding information.

For any new task:
1. Check STRUCTURE.md for project layout
2. Choose work mode → read definition from `.organon/defaults/definitions/work-modes/`
3. **Call `update_workflow_context` MCP tool** at START of work

**Key principle:** CLAUDE.md = navigation + standards. Details live in:
- `docs/` - User guides, developer guides, design docs
- `.organon/defaults/definitions/` - Work-mode and workflow specifications

## Workflow Context Tracking

Call `update_workflow_context` MCP tool when starting/switching/completing work.

**Parameters:**
- `workflow`: conversation | one-off-task | sprint-planning | sprint-execution
- `sprint_id`: Sprint directory/task name (optional)
- `task_type`: research | design | implement | test | etc (optional)
- `task_description`: Brief description of current work (optional)

## Work Organization

Choose one of four work modes:

### 1. Conversation
Discussion and planning without file changes
→ `.organon/defaults/definitions/work-modes/conversation.md`

### 2. One-Off Task
Quick work (< 2 hours): bug fixes, docs updates, simple changes
→ `.organon/defaults/definitions/work-modes/one-off-task.md`

### 3. Sprint Planning
Create implementation plan - choose format based on needs:
- **Standard:** High-level checklist → `work-modes/sprint-planning-standard.md`
- **Detailed:** Explicit file operations → `work-modes/sprint-planning-detailed.md`

**When user requests sprint:** Call `create_sprint(name, status="Created")`, read work-mode definition from tool response.

### 4. Sprint Execution
Execute sprint plan - format matches your plan:
- **Standard:** Manual sequential → `work-modes/sprint-execution-standard.md`
- **Detailed:** Orchestrated/parallel → `work-modes/sprint-execution-detailed.md`

**Sprint format:** `NN_Name_Status` (number assigned when status → Current)
**Sprint status:** Created → Next → Current → Completed | Paused

**See:** `docs/user-guide/sprints.md`, `docs/user-guide/backlog.md`, `docs/user-guide/workflows.md`

## Implementation Standards

**NEVER CREATE:** Mocks, stubs, placeholders, or fallbacks that return fake data
**ALWAYS:** Implement real solution OR fail explicitly with clear error message

**Additional rules:**
- Test before claiming it works
- Icons only for ✗ and ✓
- Lean testing: Golden master snapshots, integration workflows, unit tests for pure functions only

**Commit format:**
- Sprint work: `feat(sprint-NN): Description`
- Non-sprint: `bugfix:`, `docs:`, `chore:`, etc.

## Quick Reference

### File Locations

- **This file:** `CLAUDE.md` (agent navigation and standards)
- **Setup:** `README.md` (installation, quick start)
- **MCP Setup:** `MCP_SETUP.md` (MCP server installation and troubleshooting)
- **Workflow tracking:** `.organon/current-context.json` (tracked via MCP tool)
- **Navigation:** `STRUCTURE.md` (file organization)
- **User guides:** `docs/user-guide/` (sprints, backlog, workflows, orchestration)
- **Developer guides:** `docs/developer-guide/` (python-standards, testing)
- **CLI Reference:** `docs/reference/cli.md` (complete command documentation)
- **Design docs:** `docs/design/` (architecture, rationale)
- **Working docs:** `dev-docs/` (sprints, backlog, analysis, archive)
- **Package source:** `src/organon/`
- **Development scripts:** `scripts/llm_capture/` (LLM context capture and token analysis)
- **Package defaults:** `defaults/` (reference implementations shipped with package)
- **Project organon files:** `.organon/` (project-local organon configuration and runtime data)
  - `.organon/defaults/` - Reference materials (version controlled, copied from package on init)
  - `.organon/rules/` - Custom validation rules (version controlled)
  - `.organon/logs/`, `.organon/cache/` - Runtime data (gitignored)
- **Project config:** `organon.yaml` (project root, version controlled)


      IMPORTANT: this context may or may not be relevant to your tasks. You should not respond to this context unless it is highly relevant to your task.
</system-reminder>

I need to understand the workflow for LLM request capture and token analysis in this codebase. Specifically:

1. What does the extraction script do and why is it needed?
2. What's the overall workflow from capturing requests to analyzing token usage?
3. Where are the scripts located and what's their purpose?
4. Look at the llm_capture directory structure and any README or documentation

Focus on understanding the data flow: how requests are captured, extracted, and analyzed. Return a clear explanation of why the extraction step is necessary as a separate step.