context-engineering-advisor
Diagnose whether your AI workflows are context stuffing or context engineering, then implement structured practices to improve output quality.
- Distinguishes between context stuffing (volume-based) and context engineering (structure-based), with five diagnostic questions to identify Context Hoarding Disorder
- Guides two-layer memory architecture: short-term conversational memory plus long-term persistent memory via vector databases for semantic retrieval
- Implements the Research→Plan→Reset→Implement cycle to eliminate context rot and prevent goal drift during multi-phase AI workflows
- Provides falsification tests and ownership frameworks to define context boundaries, prevent unbounded growth, and establish accountability for what persists vs. retrieves
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
More from deanpeters/product-manager-skills
prd-development
Build a structured PRD that connects problem, users, solution, and success criteria. Use when turning discovery notes into an engineering-ready document for a major initiative.
1.7Kuser-story
Create user stories with Mike Cohn format and Gherkin acceptance criteria. Use when turning user needs into development-ready work with clear outcomes and testable conditions.
1.7Kroadmap-planning
Plan a strategic roadmap across prioritization, epic definition, stakeholder alignment, and sequencing. Use when turning strategy into a release plan that teams can execute.
1.5Kcompany-research
Create a company research brief with executive quotes, product strategy, and org context. Use when preparing for interviews, competitive analysis, partnerships, or market-entry work.
1.3Kproduct-strategy-session
Run an end-to-end product strategy session across positioning, discovery, and roadmap planning. Use when a team needs validated direction before committing to execution.
1.2Kprioritization-advisor
Choose a prioritization framework based on stage, team context, and stakeholder needs. Use when deciding between RICE, ICE, value/effort, or another scoring approach.
1.1K