context-engineering-advisor
Diagnose context stuffing vs. context engineering. Use when an AI workflow feels bloated, brittle, or hard to steer reliably.
Author
Category
Product DesignInstall
Download and extract to your skills directory
Copy command and send to AI Agent for auto-install:
Purpose
Guide product managers through diagnosing whether they're doing context stuffing (jamming volume without intent) or context engineering (shaping structure for attention). Use this to identify context boundaries, fix "Context Hoarding Disorder," and implement tactical practices like bounded domains, episodic retrieval, and the Research→Plan→Reset→Implement cycle.
Key Distinction: Context stuffing assumes volume = quality ("paste the entire PRD"). Context engineering treats AI attention as a scarce resource and allocates it deliberately.
This is not about prompt writing—it's about designing the information architecture that grounds AI in reality without overwhelming it with noise.
Input
Works best with: A description of the AI workflow, agent, or prompt setup that feels bloated, brittle, or hard to steer.
Also useful: What you've already stuffed into context (docs, transcripts, schemas) and where outputs go wrong.
Anything supplied with the invocation itself — text after the skill name, a pasted context dump, or an appended ARGUMENTS: line — counts as answers already given. Use it and skip whatever it covers; don't re-ask.
Arriving empty-handed? That works too. The advisor opens by asking what you're feeding the model today and what breaks.
Example invocation: Diagnose my setup: our support-triage agent gets the full 40-page policy manual per ticket and still misroutes edge cases.
Key Concepts
The Paradigm Shift: Parametric → Contextual Intelligence
The Fundamental Problem:
PM's Role Shift: From feature builder → architect of informational ecosystems that ground AI in reality
Context Stuffing vs. Context Engineering
| Dimension | Context Stuffing | Context Engineering |
|---|---|---|
| Mindset | Volume = quality | Structure = quality |
| Approach | "Add everything just in case" | "What decision am I making?" |
| Persistence | Persist all context | Retrieve with intent |
| Agent Chains | Share everything between agents | Bounded context per agent |
| Failure Response | Retry until it works | Fix the structure |
| Economic Model | Context as storage | Context as attention (scarce resource) |
Critical Metaphor: Context stuffing is like bringing your entire file cabinet to a meeting. Context engineering is bringing only the 3 documents relevant to today's decision.
The Anti-Pattern: Context Stuffing
Five Markers of Context Stuffing:
Why It Fails:
The Hidden Costs:
Real Context Engineering: Core Principles
Five Foundational Principles:
Quantitative Framework:
Efficiency = (Accuracy × Coherence) / (Tokens × Latency)Key Finding: Using RAG with 25% of available tokens preserves 95% accuracy while significantly reducing latency and cost.
The 5 Diagnostic Questions (Detect Context Hoarding Disorder)
Ask these to identify context stuffing:
Memory Architecture: Two-Layer System
Short-Term (Conversational) Memory:
Long-Term (Persistent) Memory:
- Declarative Memory: Facts ("I'm vegan")
- Procedural Memory: Behavioral patterns ("I debug by checking logs first")
LLM-Powered ETL: Models generate their own memories by identifying signals, consolidating with existing data, updating database automatically.
The Research → Plan → Reset → Implement Cycle
The Context Rot Solution:
Why This Works: Context rot is eliminated; agent starts clean with compressed, high-signal context.
Anti-Patterns (What This Is NOT)
When to Use This Skill
✅ Use this when:
❌ Don't use this when:
Facilitation Source of Truth
Use workshop-facilitation as the default interaction protocol for this skill.
It defines:
Other (specify) when useful)This file defines the domain-specific assessment content. If there is a conflict, follow this file's domain logic.
Application
This interactive skill uses adaptive questioning to diagnose context stuffing, identify boundaries, and provide tactical implementation guidance.
Step 0: Gather Context
Agent asks:
Before we diagnose your context practices, let's gather information:
Current AI Usage:
Symptoms:
System Architecture (if applicable):
You can describe briefly or paste examples.
Step 1: Diagnose Context Stuffing Symptoms
Agent asks:
Let's assess whether you're experiencing context stuffing. Which of these symptoms do you recognize?
Select all that apply:
User response: [Select symptoms]
Agent analyzes:
Based on your selections:
Agent proceeds to diagnostic questions.
Step 2: Diagnostic Question 1 — What Specific Decision Does This Support?
Agent asks:
Let's start with the most critical question: For each piece of context you're including, what specific decision does it support?
Example Context Analysis:
Imagine you're asking AI to "help with discovery planning." You're providing:
Question: What decision are you making right now?
Offer 3 scenarios:
- Context needed: User segments from PRD (2 paragraphs), prior interview themes (1 page synthesis), not full transcripts
- Context NOT needed: Meeting notes, full competitive analysis, full PRD
- Context needed: Research objectives (from PRD), past interview insights (synthesis), Jobs-to-be-Done framework
- Context NOT needed: Full competitive analysis, full meeting notes
- Problem: No specific decision = context stuffing trap
- Fix: Define the decision first, then select context
Agent recommends:
Best Practice: Before adding context, complete this sentence:
> "I need this context because I'm deciding [specific decision], and without [specific information], I can't make that decision."
If you can't complete that sentence, you don't need the context.
User response: [Describe their decision + context]
Agent validates: Does the context directly support the stated decision? If not, recommend trimming.
Step 3: Diagnostic Question 2 — Can Retrieval Replace Persistence?
Agent asks:
Second question: Is this information you always need, or something you can retrieve just-in-time?
The Distinction:
Always-Needed (Persist):
Episodic (Retrieve on-demand):
Key Insight: Just-in-time retrieval beats always-available. Don't persist what you can retrieve.
Offer 3 options:
- Assessment: Good instinct; verify with Question 4 (what fails if excluded?)
- Recommendation: Build constraints registry and operational glossary (persist these)
- Assessment: Perfect candidate for RAG or retrieval
- Recommendation: Implement semantic search; retrieve only relevant chunks for each query
- Assessment: Classic Context Hoarding Disorder symptom
- Fix: Apply Question 4 test to each piece of context
Agent recommends:
Rule of Thumb:
User response: [Categorize their context]
Agent provides: Specific recommendations on what to persist vs. retrieve.
Step 4: Diagnostic Question 3 — Who Owns the Context Boundary?
Agent asks:
Third question: Who is responsible for defining what belongs in vs. out of your AI's context?
The Ownership Problem:
If no one owns the context boundary, it will grow indefinitely. Every PM will add "just one more thing," and six months later, you're stuffing 100k tokens per query.
Offer 3 options:
- Assessment: Good—you can make fast decisions
- Recommendation: Document your boundary criteria (use Questions 1-5 as framework)
- Assessment: Can work if formalized
- Recommendation: Create a "Context Manifest" doc: what's always included, what's retrieved, what's excluded (and why)
- Assessment: Critical risk; boundary will expand uncontrollably
- Fix: Assign explicit ownership; schedule quarterly context audits
Agent recommends:
Best Practice: Create a Context Manifest
# Context Manifest: [Product/Feature Name]
## Always Persisted (Core Context)
- Product constraints (technical, regulatory)
- User preferences (role, permissions, preferences)
- Operational glossary (20 key terms)
## Retrieved On-Demand (Episodic Context)
- Historical PRDs (retrieve via semantic search)
- User interview transcripts (retrieve relevant quotes)
- Competitive analysis (retrieve when explicitly needed)
## Excluded (Out of Scope)
- Meeting notes older than 30 days (no longer relevant)
- Full codebase (use code search instead)
- Marketing materials (not decision-relevant)
## Boundary Owner: [Name]
## Last Reviewed: [Date]
## Next Review: [Date + 90 days]User response: [Describe current ownership model]
Agent provides: Recommendation on formalizing ownership + template for Context Manifest.
Step 5: Diagnostic Question 4 — What Fails if We Exclude This?
Agent asks:
Fourth question: For each piece of context, what specific failure mode occurs if you exclude it?
This is the falsification test. If you can't identify a concrete failure, you don't need the context.
Offer 3 scenarios:
- Failure Mode: Clear and concrete
- Assessment: Valid reason to persist constraints
- Failure Mode: Vague and hypothetical
- Assessment: Historical context rarely needed for current decisions
- Fix: Retrieve PRDs only when explicitly referencing past decisions
- Failure Mode: None identified
- Assessment: Context stuffing; delete immediately
Agent recommends:
The Falsification Protocol:
For each context element, complete this statement:
> "If I exclude [context element], then [specific failure] will occur in [specific scenario]."
Examples:
User response: [Apply falsification test to their context]
Agent provides: List of context elements to delete (no concrete failure identified).
Step 6: Diagnostic Question 5 — Are We Fixing Structure or Avoiding It?
Agent asks:
Fifth question: Is adding more context solving a problem, or masking a deeper structural issue?
The Root Cause Question:
Context stuffing often hides bad information architecture. Instead of fixing messy, ambiguous documents, teams add more documents hoping AI will "figure it out."
Offer 3 options:
- Assessment: You're masking a structural problem
- Fix: Clean up the docs first (remove ambiguity, add constraints, define terms)
- Example: Instead of pasting 5 conflicting PRDs, reconcile them into 1 Source of Truth
- Assessment: You're compensating for missing foundations
- Fix: Build the glossary (20-30 key terms); AI can reference it reliably
- Example: Define "active user," "churn," "engagement" unambiguously
- Assessment: You're avoiding constraint engineering
- Fix: Create constraints registry (technical, regulatory, strategic)
- Example: Document "We won't build mobile apps" vs. explaining it in every prompt
Agent recommends:
The Structural Health Test:
If you're adding context to compensate for:
User response: [Identify structural issues]
Agent provides: Prioritized list of structural fixes before adding more context.
Step 7: Define Memory Architecture
Agent asks:
Based on your context needs, let's design a two-layer memory architecture.
Your Context Profile (from previous steps):
Recommended Architecture:
Short-Term (Conversational) Memory:
Long-Term (Persistent) Memory:
- Declarative Memory: Facts (e.g., "We follow HIPAA regulations")
- Procedural Memory: Behavioral patterns (e.g., "Always validate feasibility before usability")
Retrieval Strategy (Episodic Context):
Agent offers:
Would you like me to:
User response: [Selection]
Step 8: Implement Research → Plan → Reset → Implement Cycle
Agent asks:
Now let's implement the Research → Plan → Reset → Implement cycle to prevent context rot.
The Problem: As agents research, context windows grow chaotic—filled with dead ends, errors, and noise. This dilutes attention and causes goal drift.
The Solution: Compress research into a high-density plan, then clear the context window before implementing.
The Four-Phase Cycle:
Phase 1: Research (Chaotic Context Allowed)
Phase 2: Plan (Synthesis)
- Decision made
- Evidence supporting decision
- Constraints applied
- Next steps (sequenced)
Phase 3: Reset (Clear Context Window)
Phase 4: Implement (Fresh Session with Plan Only)
Agent offers 3 options:
- Agent provides structured template for high-density plans
- Agent walks through concrete PM use case (e.g., discovery planning)
- Agent provides step-by-step implementation guide
User response: [Selection]
Agent provides: Tailored guidance based on selection.
Step 9: Action Plan & Next Steps
Agent synthesizes:
Based on your context engineering assessment, here's your action plan:
Immediate Fixes (This Week):
Foundation Building (Next 2 Weeks):
Long-Term Optimization (Next Month):
Success Metrics:
Agent offers:
Would you like me to:
Examples
Example 1: Solo PM Context Stuffing → Engineering
Context:
Assessment:
Diagnosis: Active Context Hoarding Disorder
Intervention:
Outcome: Token usage down 70%, output quality up significantly, responses crisp and actionable.
Example 2: Growth-Stage Team with Agent Chains
Context:
Assessment:
Diagnosis: Agent orchestration without boundaries
Intervention:
Outcome: Token usage down 60%, agent chain reliability up, costs reduced by 50%.
Example 3: Enterprise with RAG but No Context Engineering
Context:
Assessment:
Diagnosis: Retrieval without intent (RAG as context stuffing)
Intervention:
Outcome: Accuracy up 35% (from Anthropic benchmark), latency down 60%, token usage down 80%.
Common Pitfalls
1. "Infinite Context" Marketing vs. Engineering Reality
Failure Mode: Believing "1 million token context windows" means you should use all of them.
Consequence: Reasoning Noise degrades performance; accuracy drops below 20% past ~32k tokens.
Fix: Context windows are not free. Treat tokens as scarce; optimize for density, not volume.
2. Retrying Instead of Restructuring
Failure Mode: "It works if I run it 3 times" → normalizing retries instead of fixing structure.
Consequence: Wastes time and money; masks deeper context rot issues.
Fix: If retries are common, your context structure is broken. Apply Q5 (fix structure, don't add volume).
3. No Context Boundary Owner
Failure Mode: Ad-hoc, implicit context decisions → unbounded growth.
Consequence: Six months later, every query stuffs 100k tokens per interaction.
Fix: Assign explicit ownership; create Context Manifest; schedule quarterly audits.
4. Mixing Always-Needed with Episodic
Failure Mode: Persisting historical data that should be retrieved on-demand.
Consequence: Context window crowded with irrelevant information; attention diluted.
Fix: Apply Q2 test: persist only what's needed in 80%+ of interactions; retrieve the rest.
5. Skipping the Reset Phase
Failure Mode: Never clearing context window during Research→Plan→Implement cycle.
Consequence: Context rot accumulates; goal drift; dead ends poison implementation.
Fix: Mandatory Reset phase after Plan; start implementation with only high-density plan as context.