/context-engineering-advisor
Diagnose context stuffing vs. context engineering. Use when an AI workflow feels bloated, brittle, or hard to steer reliably.
$ npx -y skills add getcrew44/crew44 --skill context-engineering-advisor --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
- Fires itselfAuto-invocation. Claude auto-loads it when your prompt matches the work.Auto-invocation is when the right skill fires by itself at the right moment, driven by a FLOW.md router and a hook, instead of you invoking it by name. It is the difference between a skill being installed and a skill actually getting used.Read the full definition →
- You can call itInvoke it directly when you want it.
- Slash command
/context-engineering-advisor
Context preview
The summary Claude sees to decide when to auto-load this skill.
Diagnose context stuffing vs. context engineering. Use when an AI workflow feels bloated, brittle, or hard to steer reliably.
SKILL.md
context-engineering-advisor.SKILL.mdname: context-engineering-advisor
description: Diagnose context stuffing vs. context engineering. Use when an AI workflow feels bloated, brittle, or hard to steer reliably.
intent: >-
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.
type: interactive
theme: ai-agents
best_for:
- "Diagnosing context stuffing vs. context engineering in your AI workflows"
- "Building better memory and retrieval architecture for AI agents"
- "Improving AI output quality through structured context design"
scenarios:
- "My AI outputs are mediocre even though I'm giving it lots of information — diagnose what's wrong"
- "I want to architect context properly for a multi-step AI workflow in my product team"
estimated_time: "15-20 min"
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.
Key Concepts
The Paradigm Shift: Parametric → Contextual Intelligence
**The Fundamental Problem:**
- LLMs have **parametric knowledge** (encoded during training) = static, outdated, non-attributable
- When asked about proprietary data, real-time info, or user preferences → forced to hallucinate or admit ignorance
- **Context engineering** bridges the gap between static training and dynamic reality
**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:** 1. **Reflexively expanding context windows** — "Just add more tokens!" 2. **Persisting everything "just in case"** — No clear retention criteria 3. **Chaining agents without boundaries** — Agent A passes everything to Agent B to Agent C 4. **Adding evaluations to mask inconsistency** — "We'll just retry until it's right" 5. **Normalized retries** — "It works if you run it 3 times" becomes acceptable
**Why It Fails:**
- **Reasoning Noise:** Thousands of irrelevant files compete for attention, degrading multi-hop logic
- **Context Rot:** Dead ends, past errors, irrelevant data accumulate → goal drift
- **Lost in the Middle:** Models prioritize beginning (primacy) and end (recency), ignore middle
- **Economic Waste:** Every query becomes expensive without accuracy gains
- **Quantitative Degradation:** Accuracy drops below 20% when context exceeds ~32k tokens
**The Hidden Costs:**
- Escalating token consumption
- Diluted attention across irrelevant material
- Reduced output confidence
- Cascading retries that waste time and money
---
Real Context Engineering: Core Principles
**Five Foundational Principles:** 1. **Context without shape becomes noise** 2. **Structure > Volume** 3. **Retrieve with intent, not completeness** 4. **Small working contexts** (like short-term memory) 5. **Context Compaction:** Maximize density of relevant information per token
**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:
1. **What specific decision does this support?** — If you can't answer, you don't need it 2. **Can retrieval replace persistence?** — Just-in-time beats always-available 3. **Who owns the context boundary?** — If no one, it'll grow forever 4. **What fails if we exclude this?** — If nothing breaks, delete it 5. **Are we fixing structure or avoiding it?** — Stuffing context often masks bad information architecture
---
Memory Architecture: Two-Layer System
**Short-Term (Conversational) Memory:**
- Immediate interaction history for follow-up questions
- Challenge: Space management → older parts summarized or truncated
- Lifespan: Single session
**Long-Term (Persistent) Memory:**
- User preferences, key facts across sessions → deep personalization
- Implemented via vector database (semantic retrieval)
- Two types:
- **Declarative Memory:** Facts ("I'm vegan")
- **Procedural Memory:** Behavioral patterns ("I debug by checking logs first")
- Lifespan: Persistent across sessions
**LLM-Powered ETL:** Models generate their own memories by identifying signals, consolidating with existing data, upda
Read more
name: context-engineering-advisor description: Diagnose context stuffing vs. context engineering. Use when an AI workflow feels bloated, brittle, or hard to steer reliably. intent: >- 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. type: interactive theme: ai-agents best_for: - "Diagnosing context stuffing vs. context engineering in your AI workflows" - "Building better memory and retrieval architecture for AI agents" - "Improving AI output quality through structured context design" scenarios: - "My AI outputs are mediocre even though I'm giving it lots of information — diagnose what's wrong" - "I want to architect context properly for a multi-step AI workflow in my product team" estimated_time: "15-20 min"
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.
Key Concepts
The Paradigm Shift: Parametric → Contextual Intelligence
**The Fundamental Problem:**
- LLMs have **parametric knowledge** (encoded during training) = static, outdated, non-attributable
- When asked about proprietary data, real-time info, or user preferences → forced to hallucinate or admit ignorance
- **Context engineering** bridges the gap between static training and dynamic reality
**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:** 1. **Reflexively expanding context windows** — "Just add more tokens!" 2. **Persisting everything "just in case"** — No clear retention criteria 3. **Chaining agents without boundaries** — Agent A passes everything to Agent B to Agent C 4. **Adding evaluations to mask inconsistency** — "We'll just retry until it's right" 5. **Normalized retries** — "It works if you run it 3 times" becomes acceptable
**Why It Fails:**
- **Reasoning Noise:** Thousands of irrelevant files compete for attention, degrading multi-hop logic
- **Context Rot:** Dead ends, past errors, irrelevant data accumulate → goal drift
- **Lost in the Middle:** Models prioritize beginning (primacy) and end (recency), ignore middle
- **Economic Waste:** Every query becomes expensive without accuracy gains
- **Quantitative Degradation:** Accuracy drops below 20% when context exceeds ~32k tokens
**The Hidden Costs:**
- Escalating token consumption
- Diluted attention across irrelevant material
- Reduced output confidence
- Cascading retries that waste time and money
---
Real Context Engineering: Core Principles
**Five Foundational Principles:** 1. **Context without shape becomes noise** 2. **Structure > Volume** 3. **Retrieve with intent, not completeness** 4. **Small working contexts** (like short-term memory) 5. **Context Compaction:** Maximize density of relevant information per token
**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:
1. **What specific decision does this support?** — If you can't answer, you don't need it 2. **Can retrieval replace persistence?** — Just-in-time beats always-available 3. **Who owns the context boundary?** — If no one, it'll grow forever 4. **What fails if we exclude this?** — If nothing breaks, delete it 5. **Are we fixing structure or avoiding it?** — Stuffing context often masks bad information architecture
---
Memory Architecture: Two-Layer System
**Short-Term (Conversational) Memory:**
- Immediate interaction history for follow-up questions
- Challenge: Space management → older parts summarized or truncated
- Lifespan: Single session
**Long-Term (Persistent) Memory:**
- User preferences, key facts across sessions → deep personalization
- Implemented via vector database (semantic retrieval)
- Two types:
- **Declarative Memory:** Facts ("I'm vegan")
- **Procedural Memory:** Behavioral patterns ("I debug by checking logs first")
- Lifespan: Persistent across sessions
**LLM-Powered ETL:** Models generate their own memories by identifying signals, consolidating with existing data, upda
Orchestrate a crew of specialist AI agents in one local-first workspace. Each role on its best model, with memory and skills that compound. Free, MIT.
Repo: getcrew44/crew44
Other skills on crew44.
- /brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements and design before implementation.
Open skill - /executing-plans
Use when you have a written implementation plan to execute in a separate session with review checkpoints
Open skill - /finishing-a-development-branch
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Open skill - /receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation
Open skill - /requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements
Open skill - /systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Open skill

