Context Engineering (2/3)—Product Requirements Prompts
In this blog, we will explore further on context engineering and get deep into PRPs and how RAGs can enhance the contexts.
This blog is the three part of the two-part series. In the first part, I shared my experiences building contexts to get agentic AI applications to give good results.
In this blog, I will share my practical experiences building structured contexts using PRPs (Product Requirements Prompts) and how it has changed the way Agentic AI applications work.
I had covered my experiences with vibe coding in the following blogs. Please read them.
Also please read the following blogs for a better understanding of context engineering and RAG.
Now let's dive deep into PRPs
Product Requirement Prompts (PRPs)
PRPs are like the bridge between the unstructured, real-world business conversations and the structured requirements. They transform scattered ideas, feature requests, and stakeholder feedback into actionable product specifications using the layered context approach. I had explained the layers context in part 1; please read it in case you have not.
PRPs apply context engineering principles to ensure nothing gets lost in translation between “requirements” and the actual inference and results.
Understanding the PRP Context Flow
This diagram shows how PRPs apply context engineering to transform business needs into technical requirements:
Business Context: Establishes the business domain, market conditions, and organizational constraints that shape requirements.
Stakeholder Analysis: Identifies who has input, who makes decisions, and how different perspectives need to be balanced.
Requirement Extraction: Systematically pulls functional and non-functional requirements from conversations, documents, and feedback.
Technical Translation: Converts business language into technical specifications that development teams can implement.
Specification Output: Produces structured, actionable requirements in formats that integrate with existing development workflows.
Validation Framework: Ensures requirements are complete, consistent, and testable before development begins.
PRP Context Engineering Components
Let’s look at how we can use the layers we discussed in Part 1 into a clearly structured PRP.
There are no standards or any rule that this is the only structure. Based on my experience, I have seen this structure work. You can come up with your own structure, as long as you are covering all the aspects of the context that is discussed in Part 1 and Part 2 of the blog series
A typical PRP should have the following suggested structure:
Business Context Layer: Establishes the product and market foundation. Without business context, requirements become feature lists instead of solutions to real problems.
Product vision: “We’re building a B2B SaaS platform for small accounting firms.”
Market constraints: “Must comply with SOX requirements and integrate with QuickBooks.”
Business objectives: “Reduce manual data entry by 80% and improve accuracy to 99.5%.”
Stakeholder Analysis: Maps the human context around requirements. Different stakeholders have different needs. PRPs help balance competing priorities and identify potential conflicts early.
Primary users: “Staff accountants who process 50+ transactions daily”
Decision makers: “Firm partners who evaluate ROI and compliance risk”
Technical constraints: “IT managers who need single sign-on and audit trails”
Requirement Extraction: Systematically captures what needs to be built. Incomplete requirements lead to scope creep and missed expectations. PRPs ensure nothing critical gets overlooked.
Functional requirements: “The system must automatically categorize transactions with 95% accuracy.”
Non-functional requirements: “Response time under 2 seconds for transaction processing”
Integration requirements: “Real-time sync with QuickBooks Online API”
Technical Translation: Converts business needs into development specifications. Development teams need concrete specifications, not business wishes. PRPs bridge this gap by translating intent into implementation details.
API specifications: “RESTful endpoints for transaction CRUD operations”
Data models: “Transaction entity with audit trail and approval workflow”
Performance criteria: “Handle 10,000 concurrent users with 99.9% uptime”
Specification Output: Produces actionable development artifacts. Requirements aren’t useful until they’re actionable. PRPs ensure output integrates seamlessly with existing development workflows.
User stories: “As a staff accountant, I want to bulk import transactions so I can process month-end faster.”
Acceptance criteria: “Given 100 transactions, when I import via CSV, then all valid entries are processed within 30 seconds.”
Technical specifications: “Database schema, API contracts, and integration patterns”
Validation Framework: Ensures requirement quality before development. Bad requirements are expensive to fix after development starts. PRPs catch issues early when they’re cheap to resolve.
Completeness checks: “All user journeys have corresponding acceptance criteria.”
Consistency validation: “No conflicting requirements between stakeholder groups”
Testability verification: “Each requirement can be validated through automated or manual testing.”
Context Engineering Templates and Examples
All context engineering implementations follow a five-layer architecture consisting of the System, Domain, Task, Interaction, and Response Context Layers. Here are some example templates.
Template 1: Technical Analysis Context
## Technical Analysis Context Template
### System Context Layer (Role Definition)
**AI Identity**: Senior technical analyst with 10+ years experience in [DOMAIN]
**Core Capabilities**: Statistical analysis, risk assessment, technical documentation
**Behavioral Guidelines**: Maintain objectivity, support claims with data, acknowledge limitations
**Safety Constraints**: Never make recommendations without sufficient data backing
### Domain Context Layer (Knowledge Base)
**Domain Expertise**: [SPECIFIC_TECHNICAL_DOMAIN] - standards, methodologies, best practices
**Industry Knowledge**: Current trends, regulatory requirements, competitive landscape
**Technical Standards**: Relevant frameworks, compliance requirements, quality metrics
**Terminology**: Domain-specific language and technical vocabulary
### Task Context Layer (Constraints)
**Primary Objective**: Analyze [SPECIFIC_TECHNICAL_AREA] and provide actionable insights
**Success Criteria**: Insights must be data-driven, actionable, and risk-assessed
**Input Requirements**: Technical specifications, performance data, contextual information
**Quality Standards**: 95% accuracy in analysis, all claims must be verifiable
### Interaction Context Layer (Examples)
**Communication Style**: Professional, technical but accessible
**Clarification Protocol**: Ask specific questions when data is ambiguous
**Error Handling**: Clearly state when insufficient data prevents analysis
**Feedback Mechanism**: Provide confidence levels for all recommendations
### Response Context Layer (Output Format)
**Structure**: Executive Summary → Key Findings → Technical Analysis → Recommendations → Risk Assessment
**Format Requirements**: Markdown with embedded data visualizations where appropriate
**Length Guidelines**: Executive summary (2-3 sentences), full analysis (500-1500 words)
**Delivery Standards**: Include methodology, data sources, and confidence intervalsTemplate 2: Creative Content Generation Context
## Creative Content Generation Context Template
### System Context Layer (Role Definition)
**AI Identity**: Creative content strategist with expertise in [CONTENT_TYPE]
**Core Capabilities**: Brand voice adaptation, audience analysis, content optimization
**Behavioral Guidelines**: Maintain brand consistency, prioritize audience needs, ensure originality
**Safety Constraints**: Never plagiarize, respect brand guidelines, avoid controversial topics
### Domain Context Layer (Knowledge Base)
**Content Expertise**: [SPECIFIC_CONTENT_DOMAIN] best practices, trends, formats
**Brand Knowledge**: Voice, tone, values, visual identity, messaging framework
**Audience Intelligence**: Demographics, preferences, pain points, communication patterns
**Platform Understanding**: Distribution channels, format requirements, engagement metrics
### Task Context Layer (Constraints)
**Primary Objective**: Create [CONTENT_TYPE] that achieves [SPECIFIC_GOAL]
**Success Criteria**: Aligns with brand voice, engages target audience, drives desired action
**Input Requirements**: Content brief, brand guidelines, audience profile, success metrics
**Quality Standards**: Original content, brand-compliant, optimized for target platform
### Interaction Context Layer (Examples)
**Communication Style**: Match brand voice (professional/casual/technical as specified)
**Clarification Protocol**: Ask about audience, goals, and constraints when unclear
**Error Handling**: Request additional brand guidance when requirements conflict
**Feedback Mechanism**: Provide rationale for creative decisions and alternative approaches
### Response Context Layer (Output Format)
**Structure**: Primary content → Alternative versions → Metadata → Distribution recommendations
**Format Requirements**: Platform-optimized formatting with clear CTAs where appropriate
**Length Guidelines**: Adhere to platform limits and audience attention spans
**Delivery Standards**: Include content rationale, SEO considerations, performance predictionsTemplate 3: Code Review Context
## Code Review Context Template
### System Context Layer (Role Definition)
**AI Identity**: Senior software engineer with expertise in [PROGRAMMING_LANGUAGE/FRAMEWORK]
**Core Capabilities**: Code analysis, security assessment, performance optimization
**Behavioral Guidelines**: Focus on constructive feedback, prioritize security and maintainability
**Safety Constraints**: Never approve code with security vulnerabilities, always verify claims
### Domain Context Layer (Knowledge Base)
**Technical Expertise**: [LANGUAGE/FRAMEWORK] best practices, design patterns, performance optimization
**Security Knowledge**: Common vulnerabilities, secure coding practices, threat modeling
**Quality Standards**: Code style guides, testing requirements, documentation standards
**Tooling Familiarity**: Static analysis tools, testing frameworks, deployment practices
### Task Context Layer (Constraints)
**Primary Objective**: Review code for quality, security, and maintainability
**Success Criteria**: Identify all critical issues, provide actionable feedback, ensure standards compliance
**Input Requirements**: Source code, application context, review criteria, performance requirements
**Quality Standards**: Zero critical security issues, adherence to coding standards, comprehensive feedback
### Interaction Context Layer (Examples)
**Communication Style**: Professional, constructive, educational
**Clarification Protocol**: Ask about business logic when code intent is unclear
**Error Handling**: Flag ambiguous code sections and request clarification
**Feedback Mechanism**: Categorize issues by severity, provide specific line references
### Response Context Layer (Output Format)
**Structure**: Overall Assessment → Critical Issues → Recommendations → Security Analysis → Performance Notes
**Format Requirements**: Structured feedback with code examples and specific line references
**Length Guidelines**: Comprehensive but focused, prioritize critical issues
**Delivery Standards**: Actionable recommendations, severity classification, resolution guidanceHere are some example implementations
Example Implementation 1: API Documentation Generator
### API Documentation Context Implementation
**System Context**: You are a technical writer specializing in API documentation with 8+ years experience. You prioritize developer experience and create documentation that enables quick, successful integrations.
**Domain Context**: Expert in REST APIs, GraphQL, authentication patterns (OAuth, JWT, API keys), error handling, rate limiting, and SDK development. Current with OpenAPI specifications and modern API design principles.
**Task Context**: Generate comprehensive API documentation that enables developers to integrate successfully within 30 minutes. Include all endpoints, authentication flows, error codes, and practical examples.
**Interaction Context**: Write for busy developers who need quick answers. Use clear headings, provide copy-paste examples, and anticipate common integration challenges.
**Response Context**: Deliver structured markdown documentation with:
- Quick start guide (5 minutes to first API call)
- Complete endpoint reference with examples
- Authentication guide with code samples
- Error reference with resolution steps
- SDK integration examples for popular languagesExample Implementation 2: Data Analysis Context
### Data Analysis Context Implementation
**System Context**: You are a senior data scientist with expertise in statistical analysis, machine learning, and business intelligence. You translate complex data into actionable business insights.
**Domain Context**: Expert in statistical methods, data visualization, A/B testing, predictive modeling, and business metrics. Familiar with tools like Python, R, SQL, and modern BI platforms.
**Task Context**: Analyze datasets to identify patterns, trends, and anomalies that support strategic business decisions. Ensure all findings are statistically significant and business-relevant.
**Interaction Context**: Communicate findings to both technical and non-technical stakeholders. Use clear visualizations and explain statistical concepts in business terms.
**Response Context**: Provide structured analysis with:
- Executive summary with key insights (3-5 bullet points)
- Detailed statistical analysis with methodology
- Data visualizations that support findings
- Business recommendations with expected impact
- Data quality assessment and limitationsHere is an example of how we can use PRPs to query the LLMs
Simple Code Review Example
# Using OpenAI API
curl -X POST "https://api.openai.com/v1/chat/completions" \
-H "Authorization: Bearer $OPENAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "gpt-4",
"messages": [
{"role": "system", "content": "'$(cat react-typescript-review.md | sed 's/"/\\"/g' | tr '\n' ' ')'"},
{"role": "user", "content": "Please review this React component:\n\n'$(cat UserProfile.tsx | sed 's/"/\\"/g')'"}
]
}'
# Or using Ollama locally
echo "Please review this React component:\n\n$(cat sample.tsx)" | \
ollama run codellama "$(cat react-typescript-review.md)\n\nUser: $(cat -)"Retrieval-Augmented Generation (RAG) and context engineering work together as natural partners in the development of intelligent AI systems. While context engineering provides the framework for how AI should process and respond to information, RAG supplies the dynamic knowledge that ensures those responses are accurate and current.
RAG and Context Engineering: A Powerful Partnership
Think of RAG as the AI’s research assistant, while context engineering serves as its communication coach. RAG finds the right information, while context engineering ensures that information is processed and presented correctly.
Dynamic Knowledge Integration: RAG provides fresh, relevant information that context engineering frameworks can process systematically. IInstead of relying on static knowledge, your AI gains access to current data, documents, and domain-specific information.
Context-Aware Retrieval: Context engineering principles help RAG systems retrieve more relevant information by providing structured queries and filtering criteria. The context layers guide what information to prioritize and how to interpret retrieved content.
Consistent Information Processing: RAG might retrieve varied information formats, but context engineering ensures consistent processing and output formatting regardless of the source material’s structure.
Dynamic Context Enrichment: RAG extends the already powerful capabilities of LLMs to specific domains or an organization’s internal knowledge base, all without the need to retrain the model.
Real-Time Context Updates: When new information becomes available, rather than having to retrain the model, all that’s needed is to augment the model’s external knowledge base with the updated information. This is crucial for context engineering because it allows AI systems to maintain current and accurate context without expensive retraining.
Grounding and Verification: RAG implementation in an LLM-based question-answering system ensures that the model has access to the most current, reliable facts and that users have access to the model’s sources.
The following picture shows the typical flow of how RAG brings in more relevant context and enhances the context.
RAG systems incorporate specific augmentation modules with abilities such as expanding queries into multiple domains and using memory and self-improvement to learn from previous retrievals. The model feeds this relevant retrieved information into the LLM via prompt engineering of the user’s original query.
This enables Context Engineering to work at multiple levels:
Foundation Context: Static, well-established knowledge
Dynamic Context: Real-time, changing information
Domain-Specific Context: Specialized knowledge bases
User-Specific Context: Personalized information
[Original User Query] +
[Retrieved Relevant Context] +
[Specific Instructions] = Enhanced PromptRAG-Enhanced PRP Implementation
When combining RAG with product requirement prompts, you get dynamic requirement analysis that stays current with industry standards and best practices:
Knowledge-Augmented Business Context:
RAG retrieves current market conditions and competitor analysis
Context engineering structures this information into actionable business insights
PRPs ensure requirements reflect real-world constraints and opportunities
Dynamic Technical Translation:
RAG accesses current API documentation, framework updates, and technical standards
Context engineering translates this into specific implementation guidance
Technical specifications stay current with evolving technology stacks
Real-time Validation:
RAG retrieves similar project outcomes and industry benchmarks
Context engineering applies validation frameworks to assess requirement feasibility
Requirements get validated against actual market data rather than assumptions
The following are some patterns, for using RAG to enhance the context.
Pattern 1: Expert Knowledge Synthesis
Context Layer: "You are a domain expert with access to current industry knowledge"
RAG Integration: Retrieve latest research papers, industry reports, best practices
Processing: Apply domain expertise context to synthesize retrieved information
Output: Expert-level insights backed by current dataPattern 2: Compliance-Aware Analysis
Context Layer: "Ensure all recommendations comply with current regulations"
RAG Integration: Retrieve latest regulatory updates, compliance guidelines
Processing: Filter recommendations through compliance context
Output: Compliant solutions with regulatory justificationPattern 3: Competitive Intelligence
Context Layer: "Analyze competitive landscape and market positioning"
RAG Integration: Retrieve competitor information, market analysis, pricing data
Processing: Apply strategic analysis context to competitive intelligence
Output: Strategic recommendations based on current market conditionsWrap-up
Let me wrap up and summarize both the parts. Here are some learnings and pitfalls that I think we should keep in mind when doing context engineering
Context Overload
Problem: Providing too much context can overwhelm the AI and reduce performance.
Solution: Use context layering and focus on relevant information only.
Ambiguous Instructions
Problem: Unclear or contradictory instructions lead to inconsistent outputs.
Solution: Use PRP templates to ensure consistency and clarity.
Insufficient Validation
Problem: Lack of validation criteria makes it difficult to assess output quality.
Solution: Implement comprehensive validation frameworks.
Context Drift
Problem: Context meaning changes over time or across different use cases.
Solution: Establish version control and regular context audits.
Measuring Context Engineering Success
Accuracy: Percentage of outputs that meet quality criteria
Efficiency: Time and resources required for context processing
Consistency: Variance in outputs for similar inputs
Scalability: Performance degradation with increased complexity
Maintainability: Effort required for context updates and modifications
Summary
Context engineering represents a fundamental shift in how we interact with AI systems. By applying structured approaches like PRPs and following engineering best practices, we can create more reliable, efficient, and effective AI interactions.
Good context engineering isn’t just about getting the right answer—it’s about getting the right answer consistently, efficiently, and in a way that scales with your needs.
There you go. I hope this was useful. Please leave your feedback and comments and share your experiences. I will soon be blogging about a practical example of how I am using these techniques with Claude Code/Gemini CLI. Until then… have fun :-D