Context Party

CONTEXT_PARTY Skill

Purpose: Coordinated parallel historical context gathering with 6 probes Created: 2026-01-06 Trigger: /context-party command Aliases: /context, /history, /cp Owner: G4_CONTEXT_MANAGER (G-4 Staff)

When to Use

Deploy CONTEXT_PARTY when you need historical context before making decisions:

• Complex tasks requiring precedent knowledge
• Before making architectural or design decisions
• When similar problems may have been solved before
• Pre-task context gathering for high-stakes work
• Understanding why current patterns exist
• Mining lessons from past sessions
• After SEARCH_PARTY, before PLAN_PARTY

Do NOT use for:

• Simple, well-understood tasks with clear precedent
• Emergencies (no time for historical research)
• New features with no historical analog
• When you already have complete context

Economics: Zero Marginal Wall-Clock Cost

Critical Understanding: Parallel context probes with the same timeout cost nothing extra in wall-clock time.

Sequential (BAD):        Parallel (GOOD):
6 probes × 90s each      6 probes × 90s in parallel
Total: 540s              Total: 90s (6x faster)

Implication: Always spawn all 6 probes. There is no cost savings from running fewer.

The Six Context Probes

Probe Details

PRECEDENT Probe

Focus: How have we solved similar problems before?

• Search for similar tasks in session history
• Identify successful approaches and patterns
• Extract lessons learned from comparable work
• Find reusable solutions and components
• Note what worked well and what didn't

RAG Queries:

• rag_search("similar to [task description]")
• rag_search("precedent [domain] [pattern]")

PATTERNS Probe

Focus: What recurring themes exist across sessions?

• Cross-session pattern recognition
• Repeated design approaches
• Emergent architectural patterns
• Common anti-patterns to avoid
• Evolution of thinking over time

RAG Queries:

• rag_search("pattern [domain]")
• rag_search("recurring [theme]")

CONSTRAINTS Probe

Focus: What are the known limits and gotchas?

• Documented constraints (ACGME, technical, policy)
• Known performance bottlenecks
• Edge cases and limitations
• Warning signs and red flags
• Hard limits that cannot be violated

RAG Queries:

• rag_search("constraint [domain]")
• rag_search("gotcha [technology]")
• rag_search("limitation [feature]")

DECISIONS Probe

Focus: What architectural decisions are relevant?

• Search decision history (ADRs)
• Extract rationale for key choices
• Understand trade-offs made
• Identify reversible vs irreversible decisions
• Map decision dependencies

RAG Queries:

• rag_search("decision [topic]", doc_type="decision_history")
• rag_search("ADR [domain]")
• rag_search("architecture choice [component]")

FAILURES Probe

Focus: What has broken before and why?

• Root cause analysis from past failures
• Bug patterns and common mistakes
• Regression history
• Fix effectiveness tracking
• Failure mode analysis

RAG Queries:

• rag_search("bug [component]", doc_type="bug_fix")
• rag_search("failure [domain]")
• rag_search("broke [feature]")

KNOWLEDGE Probe

Focus: What domain knowledge is relevant?

• ACGME rules and compliance knowledge
• Scheduling policies and constraints
• Resilience framework concepts
• Military medical context
• User guides and FAQs

RAG Queries:

• rag_search("ACGME [topic]", doc_type="acgme_rules")
• rag_search("scheduling [concept]", doc_type="scheduling_policy")
• rag_search("resilience [pattern]", doc_type="resilience_concepts")

Deployment Pattern

Standard Deployment: 6 Context Probes

Deploy 6 context gathering probes in parallel, each using semantic search and historical analysis:

Invocation

Full Deployment (6 probes)

/context-party

Deploys all 6 context probes on current task.

Targeted Context Gathering

/context-party "scheduling capacity constraints"

Deploys probes with explicit context focus.

Before Complex Work

# Recommended workflow
/search-party backend/app/scheduling/    # Understand current state
/context-party "capacity allocation"      # Understand history
/plan-party                               # Plan with full context

IDE Crash Prevention (CRITICAL)

DO NOT have ORCHESTRATOR spawn 6 context probes directly. This causes IDE seizure and crashes.

CORRECT Pattern:

ORCHESTRATOR → spawns 1 G4_CONTEXT_MANAGER
                    ↓
              G4_CONTEXT_MANAGER deploys 6 probes internally
              (manages parallelism, synthesizes results)

WRONG Pattern:

ORCHESTRATOR → spawns 6 probes directly → IDE CRASH

The G-4 Context Manager absorbs the parallelism complexity. ORCHESTRATOR only ever spawns 1 coordinator.

Spawn Pattern

Via G4_CONTEXT_MANAGER (CORRECT)

# ORCHESTRATOR spawns G4_CONTEXT_MANAGER who manages the 6 context probes
Task(
    subagent_type="general-purpose",
    description="G4_CONTEXT_MANAGER: CONTEXT_PARTY Commander",
    prompt="""
## Agent: G4_CONTEXT_MANAGER (G-4 Staff)

You are the G-4 Context Manager for CONTEXT_PARTY deployment.

## Mission
Deploy 6 context gathering probes in parallel. Each probe uses RAG semantic search
and historical analysis to gather relevant context for the current task.

Collect all reports and synthesize into unified context brief.

## Current Task Context
[Insert task description and goal here]

## Your Context Probes to Deploy
1. PRECEDENT - Search for similar past solutions
2. PATTERNS - Identify recurring themes
3. CONSTRAINTS - Document known limits
4. DECISIONS - Extract relevant ADRs
5. FAILURES - Analyze past breakages
6. KNOWLEDGE - Gather domain expertise

## RAG Integration

Each probe should use the RAG API for semantic search:
- Backend running: Use http://localhost:8000/api/rag/search
- MCP available: Use rag_search, rag_context tools
- Fallback: Search .claude/dontreadme/ markdown files

## Spawn each using Task tool with subagent_type="Explore"

## After all report back:
1. Cross-reference findings across probes
2. Identify relevant precedents
3. Flag conflicting decisions (escalate if unresolved)
4. Generate consolidated context brief
5. Report to ORCHESTRATOR
"""
)

Direct Deployment (Only if G4_CONTEXT_MANAGER unavailable)

# Deploy all 6 probes in parallel
# WARNING: Only use if spawning from within a coordinator, NOT from ORCHESTRATOR
# Total: 6 probes, wall-clock = single probe timeout

spawn_parallel([
    Task(subagent_type="Explore", description="PRECEDENT",
         prompt="Search for similar past solutions using RAG semantic search"),
    Task(subagent_type="Explore", description="PATTERNS",
         prompt="Identify recurring cross-session patterns and themes"),
    Task(subagent_type="Explore", description="CONSTRAINTS",
         prompt="Document known limits, gotchas, and warnings"),
    Task(subagent_type="Explore", description="DECISIONS",
         prompt="Extract relevant architectural decisions and rationale"),
    Task(subagent_type="Explore", description="FAILURES",
         prompt="Analyze past failures, root causes, and fixes"),
    Task(subagent_type="Explore", description="KNOWLEDGE",
         prompt="Gather domain expertise from RAG knowledge base"),
])

Context Synthesis

After all 6 probes report back:

1. Cross-reference findings across probes
2. Identify conflicts in historical decisions
3. Extract high-confidence patterns (multiple probes agree)
4. Flag gaps requiring new decisions
5. Generate consolidated context brief

Conflict Analysis

Key Insight: Same topic, different perspectives. Conflicts between probes are high-signal:

Confidence Scoring

High Confidence (4+ probes agree):
  - Pattern is well-established
  - Decision is validated by multiple sources
  - Constraint is consistently documented

Medium Confidence (2-3 probes agree):
  - Emerging pattern
  - Recent decision with limited validation
  - Constraint with edge cases

Low Confidence (0-1 probes):
  - Novel situation
  - No historical precedent
  - New decision needed

Output Format

Context Brief

## CONTEXT_PARTY Brief

### Task: [Current task description]

### Context Confidence: [HIGH/MEDIUM/LOW]

---

### PRECEDENT Findings
- **Similar Solutions:**
  - [Past solution 1] (Session X, [date])
  - [Past solution 2] (Session Y, [date])
- **Proven Approaches:**
  - [Approach A]: Worked well for [use case]
  - [Approach B]: Failed for [use case], avoid
- **Reusable Components:**
  - [Component/pattern to reuse]

---

### PATTERNS Identified
- **Recurring Theme 1:** [Description, frequency, evolution]
- **Recurring Theme 2:** [Description, frequency, evolution]
- **Anti-Patterns to Avoid:**
  - [Anti-pattern A]: Causes [problem]

---

### CONSTRAINTS Documented
- **Hard Limits:**
  - [Constraint 1]: Cannot violate [reason]
  - [Constraint 2]: ACGME rule [reference]
- **Gotchas:**
  - [Gotcha A]: Watch for [issue]
  - [Gotcha B]: Known edge case [description]
- **Performance Limits:**
  - [Limit]: Degrades at [threshold]

---

### DECISIONS Relevant
- **ADR-XXX:** [Decision summary]
  - **Rationale:** [Why this was chosen]
  - **Trade-offs:** [What was sacrificed]
  - **Status:** [Active/Superseded/Under Review]
- **Related Decisions:**
  - Depends on: [Prior decision]
  - Enables: [Future decision]

---

### FAILURES Analyzed
- **Failure Pattern 1:**
  - **What broke:** [Component/feature]
  - **Root cause:** [Why it broke]
  - **Fix:** [How it was resolved]
  - **Prevention:** [How to avoid]
- **Regression Risk:**
  - [Feature X]: Broke in [session], watch for recurrence

---

### KNOWLEDGE Retrieved
- **ACGME Compliance:**
  - [Relevant rule 1]
  - [Relevant rule 2]
- **Scheduling Policies:**
  - [Policy A]: [Description]
- **Domain Expertise:**
  - [Concept]: [Explanation from RAG]

---

### Conflicts Detected
- **CONFLICT:** [Probe A] vs [Probe B]
  - **A says:** [Position A]
  - **B says:** [Position B]
  - **Resolution needed:** [Escalate/Newer decision wins/Clarify]

---

### Gaps Identified
- **No precedent for:** [Novel aspect]
- **No constraint documented for:** [Uncovered area]
- **Decision needed for:** [Unresolved choice]

---

### Recommendations
1. **Follow precedent:** [Specific recommendation]
2. **Respect constraints:** [Specific constraint to honor]
3. **Avoid pattern:** [Specific anti-pattern to avoid]
4. **New decision needed:** [Escalate to ARCHITECT/ORCHESTRATOR]

---

### RAG Coverage
- Total chunks retrieved: [N]
- Doc types searched: [List]
- Oldest relevant context: [Date]
- Newest relevant context: [Date]

Integration with RAG System

RAG API Usage (Preferred)

When backend is running at http://localhost:8000:

# Search for precedent
curl -X POST http://localhost:8000/api/rag/search \
  -H "Content-Type: application/json" \
  -d '{
    "query": "schedule capacity allocation past approaches",
    "limit": 10,
    "doc_type": "session_learnings"
  }'

# Search for decisions
curl -X POST http://localhost:8000/api/rag/search \
  -H "Content-Type: application/json" \
  -d '{
    "query": "capacity constraint architecture decision",
    "limit": 5,
    "doc_type": "decision_history"
  }'

# Search for failures
curl -X POST http://localhost:8000/api/rag/search \
  -H "Content-Type: application/json" \
  -d '{
    "query": "scheduling engine failure capacity",
    "limit": 5,
    "doc_type": "bug_fix"
  }'

MCP Tools (If Available)

Fallback Strategy

If RAG API unavailable:

1. Search .claude/dontreadme/sessions/ for session history
2. Search .claude/dontreadme/synthesis/PATTERNS.md for patterns
3. Search .claude/dontreadme/synthesis/DECISIONS.md for decisions
4. Search docs/rag-knowledge/ for domain knowledge
5. Use git log and blame for change history

Decision Tree: When to Deploy

Workflow Integration

Full Intelligence Pipeline

User Request: Complex task
    ↓
ORCHESTRATOR receives task
    ↓
G2_RECON deploys SEARCH_PARTY
    ↓ (current state intel)
G4_CONTEXT_MANAGER deploys CONTEXT_PARTY
    ↓ (historical context)
G5_PLANNING deploys PLAN_PARTY
    ↓ (execution plan informed by state + history)
ORCHESTRATOR executes plan
    ↓
Result synthesis
    ↓
G4_CONTEXT_MANAGER captures new context (closes loop)

Signal Flow

CONTEXT_PARTY → Historical Brief → PLAN_PARTY → Execution Plan
     |                                 |              |
(6 context signals)            (informed by history)  (execution)
     |                                 |              |
Synthesis                          Strategy          Result
(G4_CONTEXT_MANAGER)             (G5_PLANNING)    (COORD_AAR)
     |                                                |
     └────────────── Capture & Store ─────────────────┘
                    (Context loop closes)

Timeout Profiles

Failure Recovery

Minimum Viable Context

Mission can proceed if:

• PRECEDENT (baseline: has this been done before?) ✓
• CONSTRAINTS (safety: what can't we do?) ✓
• KNOWLEDGE (domain: what rules apply?) ✓
• At least 2 of remaining 3 probes

Circuit Breaker

If > 2 consecutive probe failures: Trip to OPEN state, fall back to manual context gathering.

Curation After Context Gathering

CRITICAL: After completing work informed by CONTEXT_PARTY, G4_CONTEXT_MANAGER should:

1. Capture new context from task outcome
2. Update RAG knowledge base with learnings
3. Mark superseded decisions if new approach chosen
4. Link to precedent for future retrieval
5. Close the context loop

This ensures future CONTEXT_PARTY deployments benefit from current work.

Related Skills

Related Agents

CONTEXT_PARTY: Six lenses on history, one task, zero marginal cost. Those who forget context are doomed to repeat mistakes.