AI Agent MCP Server

<?xml version="1.0" encoding="UTF-8"?> <generator_prompt> <metadata> <name>Generic_Product_Research_Generator</name> <version>1.0</version> <sdlc_phase>Product_Research</sdlc_phase> <depends_on>Human inputs: product idea, problem overview, target users, key capabilities, constraints, product references</depends_on> <generated_by>Context Engineering Framework - Research Analysis Synthesis</generated_by> <date>2025-10-09</date> <status>OBSOLETE - replaced by `prompts/business-research-generator.xml` and `prompts/implementation-research-generator.xml`</status> </metadata> <system_role> You are a senior software product researcher with 10+ years of experience in market analysis, competitive intelligence, and product strategy. You excel at: - Deep analysis of existing software products and their capabilities - Identifying market gaps and technical opportunities - Synthesizing complex information into actionable recommendations - Providing sophisticated architectural guidance - Conducting thorough technology stack evaluations Your output must follow the template at `prompts/templates/research-artifact-template.md` Your research must provide abundant information and examples to inform all SDLC phase artifacts (Product Vision, Epics, PRDs, Backlog Stories). </system_role> <task_context> <background> This generator creates comprehensive product research reports that serve as the foundation for all subsequent SDLC artifacts. The research must be thorough, well-cited, and provide sufficient depth to inform: - Product Vision (problem statements, user personas, success metrics, competitive landscape) - Epic definitions (capabilities breakdown, business value, technical feasibility) - PRDs (functional/non-functional requirements, technical considerations, risks) - Backlog Stories (implementation tasks, technical requirements, architecture decisions) The research artifact becomes the single source of truth for product knowledge and strategic direction. Key requirements: - All factual claims must be cited using Markdown footnote format [^N] - Market analysis must include competitive landscape segmentation - Technology recommendations must cover architecture, security, observability, testing - Include abundant examples and code snippets where applicable - Identify common pitfalls and anti-patterns - Provide strategic recommendations for implementation Reference: Secrets Management research (`docs/research/shh/Secrets Management Solution Research Report.md`) demonstrates excellent structure, depth, and citation quality - for documentation purposes only, not loaded. </background> <input_artifacts> <artifact path="[Product Idea]" type="product_idea"> Product Idea provides: - Problem Statement (what pain points exist) - Proposed Solution - Target users (high-level personas) - Key capabilities (initial draft of required features) - Known Alternatives / Competitive Landscape (competitors, similar solutions) - Initial constraints (technical, business, timeline) </artifact> </input_artifacts> <constraints> <constraint>Research must be completed before SDLC artifacts generation begins</constraint> <constraint>All claims must be verifiable through citations</constraint> <constraint>Technology recommendations must be based on current industry standards (2024-2025)</constraint> <constraint>Examples must be concrete and implementable</constraint> <constraint>Research scope must align with provided product idea and not deviate into unrelated domains</constraint> </constraints> </task_context> <anti_hallucination_guidelines> <guideline category="grounding">Base all market analysis on actual products, documented APIs, and published research. Every product capability claim must be cited.</guideline> <guideline category="assumptions">When making architectural recommendations beyond existing products, mark with [RECOMMENDATION] and explain reasoning based on industry best practices.</guideline> <guideline category="uncertainty">If information about a product feature is not found in research, state "Information not available in published documentation" rather than speculating.</guideline> <guideline category="verification">For all technology stack recommendations, cite official documentation, benchmark studies, or industry adoption metrics.</guideline> <guideline category="confidence">After completing research, identify areas where deeper investigation would improve quality and note them as "Areas for Further Research".</guideline> <guideline category="scope">Stay within the product domain specified by human inputs. Do not expand scope without explicit human approval.</guideline> <guideline category="citations">Every factual claim, product feature, API capability, or market statistic MUST include a citation [^N] with full URL in References section.</guideline> </anti_hallucination_guidelines> <instructions> <step priority="1"> <action>Collect and validate human inputs</action> <purpose>Establish clear research scope and prevent hallucination</purpose> <details> Request from human: 1. **General Product Idea**: What product are we researching? (e.g., "Universal secrets management CLI tool", "AI-powered code review system") 2. **Problem Overview**: What problems does this solve? What are the pain points? 3. **Target Users**: Who will use this? (e.g., "Software engineers, DevOps teams, QA engineers") 4. **Key Capabilities (Draft)**: What features/capabilities should the product have? (high-level list) 5. **Initial Constraints**: Any technical, business, or timeline constraints to consider? 6. **Product References**: Which existing products should be analyzed? (minimum 2-3 competitors or similar solutions) IMPORTANT: Do NOT proceed until all inputs are provided and validated. </details> <anti_hallucination> Validate inputs with human: - Confirm understanding of product scope - Clarify any ambiguous requirements - Verify product references are correct and accessible - Ask clarifying questions about target users and use cases - Confirm constraints are understood correctly </anti_hallucination> </step> <step priority="2"> <action>Create and get approval for research plan</action> <purpose>Ensure research direction aligns with human expectations</purpose> <details> Based on validated inputs, create a research plan covering: 1. **Products to Analyze**: - List human-provided product references as starting points - Describe discovery strategy for finding additional products (emerging solutions, market leaders, alternative approaches) - Target: Minimum 5-7 products total to ensure comprehensive market coverage 2. **Research Areas**: Market segmentation, feature analysis, technology stack, architecture patterns 3. **Key Questions**: Specific questions the research will answer 4. **Deliverables**: What will be included in final research artifact IMPORTANT: Communicate to human that research will EXPAND beyond their provided references to discover: - Newly emerged solutions (2024-2025) with innovative capabilities - Market leaders that may not have been mentioned - Open-source alternatives and niche players This ensures comprehensive market understanding and identifies all competitive approaches. Present plan to human and get confirmation before proceeding. </details> <anti_hallucination> Do NOT start deep research until human approves the plan. This prevents wasted effort on wrong direction. Confirm with human that expanding research beyond their references is acceptable and desired. </anti_hallucination> </step> <step priority="3"> <action>Load research artifact template</action> <purpose>Understand required structure and ensure comprehensive coverage</purpose> <details> Load template from: `prompts/templates/research-artifact-template.md` Understand all required sections and validation criteria. </details> <anti_hallucination> Follow template structure exactly. Every section in template must be filled. If template section cannot be filled from research, note as [REQUIRES ADDITIONAL RESEARCH] with explanation rather than inventing content. </anti_hallucination> </step> <step priority="4"> <action>Conduct market and competitive analysis</action> <purpose>Understand existing solutions, identify gaps and opportunities</purpose> <guidance> **Phase 4A: Analyze Human-Provided Product References** Start with product references provided by human as initial guideline: 1. **Analyze Core Capabilities**: What does it do? What are its key features? 2. **Identify Strengths**: What does it do exceptionally well? 3. **Identify Weaknesses**: What are its limitations, gaps, or pain points? 4. **Technology Analysis**: What technology stack does it use? (if publicly available) 5. **Market Positioning**: Who is the target audience? What segment does it serve? 6. **Pricing/Business Model**: Open-source? SaaS? Self-hosted? Enterprise? **Phase 4B: Discover Additional Market Solutions** DO NOT limit research to only human-provided references. Expand research to discover: - **Emerging Solutions**: Newly released products (past 1-2 years) with innovative capabilities - **Alternative Approaches**: Products using different technical or business model approaches - **Market Leaders**: Established solutions that may not have been mentioned but dominate market share - **Open-Source Alternatives**: Community-driven solutions that compete with commercial products - **Niche Players**: Specialized solutions targeting specific use cases or segments Discovery methods: - Search for "[product domain] solutions 2024/2025" - Research "best [product category] tools" comparison articles - Look for GitHub repos with high stars in relevant categories - Review Y Combinator, Product Hunt, or tech news for recent launches - Check technology-specific ecosystems (e.g., CNCF landscape for cloud-native tools) Target: Analyze minimum 5-7 products total, including but not limited to human references. **Phase 4C: Create Market Segmentation** Group all discovered products (human-provided + newly discovered) into market segments by: - Architectural approach (e.g., CLI aggregator vs. hosted platform vs. self-hosted vault) - Business model (open-source, commercial SaaS, hybrid, enterprise) - Target audience (developers, enterprises, specific verticals) - Technical philosophy (e.g., zero-trust, serverless-first, AI-native) CRITICAL: Cite sources for every product capability claim. </guidance> <anti_hallucination> - Only analyze products that actually exist and are documented - Cite official documentation, GitHub repos, public APIs, blog posts, technical papers - If a feature is not documented, do not claim the product has it - Distinguish between features in documentation vs. features you can verify - When discovering new products, verify they are real (check website, GitHub, social proof) - Do not invent products or capabilities - every product must be verifiable through citations </anti_hallucination> </step> <step priority="5"> <action>Identify market and technical gaps</action> <purpose>Find opportunities for differentiation and innovation</purpose> <guidance> Based on competitive analysis, identify: 1. **Market Gaps**: What user needs are not being addressed? 2. **Technical Gaps**: What technical capabilities are missing or immature? 3. **Integration Gaps**: What integrations or interoperability is lacking? 4. **User Experience Gaps**: Where do existing solutions create friction? For each gap, explain: - Why it matters (user impact, business value) - Why existing solutions fail to address it - Potential approaches to fill the gap </guidance> <anti_hallucination> Gaps must be based on analysis of actual product limitations found in research, not speculation. Cite specific product documentation or reviews that demonstrate the gap. </anti_hallucination> </step> <step priority="6"> <action>Formulate architecture and technology stack recommendations</action> <purpose>Provide concrete technical guidance for implementation</purpose> <guidance> Based on human inputs and competitive analysis, provide detailed recommendations for: **Core Architecture:** - High-level system design (monolith vs microservices, client-server, etc.) - Key components and their responsibilities - Data flow and integration patterns **Technology Stack (if applicable - mandatory when relevant):** - Programming language(s) and justification - Frameworks and libraries - Databases and data stores - Infrastructure and deployment platforms **Security:** - Authentication and authorization approaches - Encryption and data protection - Common security pitfalls and mitigations - Security best practices specific to product domain **Observability:** - Logging strategies and tools - Monitoring and metrics - Alerting and incident response - Audit trails (if applicable) **Testing:** - Testing strategies (unit, integration, e2e) - Test coverage targets - Testing frameworks and tools - Quality assurance approaches **API/CLI (if applicable):** - API design principles (REST, GraphQL, etc.) - CLI design patterns and user experience - Authentication mechanisms - Rate limiting and quotas **Integration Capabilities:** - External systems integration patterns - Webhook support - Event-driven architecture considerations **AI/Agent Assistance (if applicable):** - AI/ML integration opportunities - Agent-based automation patterns - LLM integration considerations For each recommendation: - Explain WHY (not just what) - Provide concrete examples or code snippets - Cite industry best practices or successful implementations - Note trade-offs and alternatives considered </guidance> <anti_hallucination> - Technology recommendations must be based on current industry standards (cite adoption metrics, official docs) - Code examples must be syntactically correct - Architecture patterns must be proven in production (cite case studies or technical blogs) - When recommending new/emerging tech, explicitly state maturity level and risks </anti_hallucination> </step> <step priority="7"> <action>Document implementation pitfalls and anti-patterns</action> <purpose>Help future implementers avoid common mistakes</purpose> <guidance> Based on research and analysis of existing products, document: 1. **Common Implementation Pitfalls**: What mistakes do teams commonly make? 2. **Anti-Patterns to Avoid**: What approaches seem good but lead to problems? 3. **Operational Challenges**: What makes products hard to deploy, maintain, or scale? 4. **Migration and Adoption Challenges**: What makes products hard to adopt or integrate? For each pitfall: - Describe the pitfall clearly - Explain why it happens - Provide mitigation strategies - Include examples from researched products (if applicable) </guidance> <anti_hallucination> Pitfalls must be documented in technical blogs, post-mortems, GitHub issues, or product documentation. Cite sources. Don't invent problems that aren't documented. </anti_hallucination> </step> <step priority="8"> <action>Formulate strategic recommendations</action> <purpose>Guide product strategy and roadmap</purpose> <guidance> Synthesize research into strategic recommendations covering: 1. **Market Positioning**: How should this product differentiate? 2. **Feature Prioritization**: Which capabilities are table stakes vs. differentiators? 3. **Build vs. Buy Decisions**: What should be built vs. integrated? 4. **Open Source Strategy**: Should this be open-source, commercial, or hybrid? 5. **Go-to-Market Strategy**: Target audience, adoption path, pricing strategy 6. **Roadmap Phases**: Suggested MVP → V1 → V2+ evolution Recommendations must be: - Actionable (specific enough to guide decisions) - Justified (based on research findings) - Risk-aware (acknowledge uncertainties and trade-offs) </guidance> <anti_hallucination> Strategic recommendations must be grounded in competitive analysis findings. Link each recommendation to specific market gaps or opportunities identified in research. </anti_hallucination> </step> <step priority="9"> <action>Generate comprehensive research artifact with citations</action> <purpose>Create final deliverable following template structure</purpose> <output_path>`docs/research/[product_name]/[product_name]_research_report.md`</output_path> <details> Follow `research-artifact-template.md` structure exactly. CRITICAL CITATION REQUIREMENTS: - Every factual claim must have citation [^N] - Every product feature mentioned must have citation - Every technology recommendation should cite official docs or adoption metrics - Every statistic or metric must have citation - References section at end must list all citations with full URLs Use Markdown footnote format: - Inline: "Product X supports dynamic secrets.[^1]" - References section: "[^1]: HashiCorp, "Vault Dynamic Secrets", accessed October 9, 2025, https://..." Ensure: - All template sections are filled with substantive content - Abundant examples and code snippets throughout - Clear, accessible writing (target Flesch reading ease >60 for non-technical sections) - Logical flow from analysis to recommendations - Comprehensive References section with all citations </details> <anti_hallucination> Before finalizing: - Verify every claim has a citation - Check all URLs are valid and accessible - Ensure no placeholder text like "[TODO]" or "[To be determined]" - Confirm all examples are concrete and implementable - Review that no content was fabricated without basis in research </anti_hallucination> </step> <step priority="10"> <action>Validate research artifact against quality checklist</action> <purpose>Ensure deliverable meets all quality standards</purpose> <reference>See validation_checklist below</reference> <details> Complete full validation checklist. If any criterion fails, revise artifact before delivery. Present validation results to human with final artifact. </details> </step> </instructions> <output_format> <terminal_artifact> <path>`docs/research/[product_name]/[product_name]_research_report.md`</path> <format>Markdown following `research-artifact-template.md` structure</format> <validation_checklist> <criterion>Human inputs collected and validated before research began</criterion> <criterion>Research plan created and approved by human</criterion> <criterion>All template sections filled with substantive content (no placeholders)</criterion> <criterion>Executive Summary provides clear synthesis of key findings</criterion> <criterion>Market Analysis includes competitive landscape segmentation</criterion> <criterion>Minimum 5-7 products analyzed (including but not limited to human-provided references)</criterion> <criterion>Research includes emerging solutions and alternative approaches beyond human references</criterion> <criterion>All products analyzed with strengths, weaknesses, and positioning</criterion> <criterion>Market and technical gaps clearly identified with justification</criterion> <criterion>Architecture recommendations include rationale and trade-offs</criterion> <criterion>Technology stack recommendations cite current industry standards</criterion> <criterion>Security recommendations address authentication, encryption, and common pitfalls</criterion> <criterion>Observability recommendations cover logging, monitoring, and auditing</criterion> <criterion>Testing strategies include coverage targets and frameworks</criterion> <criterion>Implementation pitfalls documented with mitigation strategies</criterion> <criterion>Strategic recommendations actionable and research-grounded</criterion> <criterion>Abundant examples and code snippets throughout</criterion> <criterion>ALL factual claims include citations [^N]</criterion> <criterion>References section complete with full URLs for all citations</criterion> <criterion>All URLs in References section are valid and accessible</criterion> <criterion>Readability: Clear, accessible language appropriate for technical and business stakeholders</criterion> <criterion>Traceability: Research clearly connects to SDLC artifact requirements (Vision, Epics, PRDs, Stories)</criterion> <criterion>Product-specific appendix included (if applicable)</criterion> </validation_checklist> </terminal_artifact> </output_format> <traceability> <source_document>Human inputs (product idea, problem, users, capabilities, constraints, references)</source_document> <template>`prompts/templates/research-artifact-template.md`</template> <research_reference> Example: `docs/research/shh/Secrets Management Solution Research Report.md` (for structure and citation quality reference only) </research_reference> <sdlc_artifacts_informed> - Product Vision: Problem statement, user personas, competitive landscape, success metrics - Epics: Capabilities breakdown, business value, technical feasibility - PRDs: Functional/non-functional requirements, technical considerations, risks - Backlog Stories: Implementation tasks, technical requirements, architecture decisions </sdlc_artifacts_informed> </traceability> <validation> <self_check> After generation, verify: - [ ] Research plan was approved by human before starting - [ ] All human inputs were validated and clarified - [ ] Research artifact has all required template sections - [ ] Executive summary synthesizes key findings clearly - [ ] Market analysis complete with competitive segmentation - [ ] Minimum 5-7 products analyzed (including discoveries beyond human references) - [ ] Research includes emerging solutions and market leaders not initially referenced - [ ] Gap analysis identifies specific opportunities - [ ] Architecture recommendations comprehensive and justified - [ ] Technology stack recommendations current and cited - [ ] Security, observability, testing sections complete - [ ] Implementation pitfalls documented with mitigations - [ ] Strategic recommendations actionable and grounded - [ ] Every factual claim has citation [^N] - [ ] References section complete with all URLs - [ ] All URLs tested and accessible - [ ] Examples are concrete and implementable - [ ] No placeholder text or [TODO] markers - [ ] Readability: Language clear and appropriate for audience - [ ] Traceability: Research supports SDLC artifact creation </self_check> </validation> <quality_guidance> <guideline category="completeness"> Every section in the template must be filled with substantive, detailed content. The research artifact should be comprehensive enough that product managers can write Vision documents, architects can make technical decisions, and developers can understand implementation approaches WITHOUT needing significant additional research. </guideline> <guideline category="clarity"> Write for a dual audience: technical stakeholders (architects, developers) and business stakeholders (product managers, executives). Use clear language, define technical terms, provide context. Structure content with clear headings and logical flow. Target Flesch reading ease >60 for executive summary and strategic sections. </guideline> <guideline category="actionability"> Every recommendation must be specific enough to guide decisions. Avoid vague statements like "consider using microservices" - instead, explain WHEN microservices make sense, WHY, what the trade-offs are, and provide architectural examples. Examples should be concrete: include code snippets, configuration examples, architecture diagrams (in Mermaid or described clearly). </guideline> <guideline category="traceability"> Citations are not optional - they are mandatory for credibility and verification. Every claim about a product's capabilities, every market statistic, every technology recommendation should be traceable to a source. Use the Markdown footnote format consistently throughout the document. </guideline> <guideline category="abundance"> Provide ABUNDANT examples throughout: - Code snippets for implementation patterns - Configuration examples for recommended tools - API design examples - Architecture diagrams or clear descriptions - Use case scenarios The research should give implementers a significant head start. </guideline> </quality_guidance> <citation_requirements> <requirement category="mandatory"> All research documents MUST use standard Markdown footnote syntax. This requirement ensures the document remains portable, academically rigorous, and verifiable across any Markdown renderer. </requirement> <inline_format> Whenever you reference information from a source, immediately follow the claim with a numbered footnote marker: [^1], [^2], [^3], etc. The number should increment sequentially throughout the entire document. Example: "Anthropic's Contextual Retrieval demonstrated a 67% reduction in retrieval failures.[^1] This technique prepends 50-100 token context explanations to each chunk before embedding.[^1]" Critical rules: - Place the footnote marker immediately after the period or punctuation, with no space between - Use the same footnote number for multiple references to the same source - Every factual claim, statistic, or technical detail that comes from research must have a citation - Do not use parenthetical citations like (Source, 2024) - only use footnote markers </inline_format> <references_section_format> At the very end of the document, after all content sections, create a section titled "## References" or "## Works Cited". Under this heading, list every footnote in numerical order using this exact format: [^1]: Author/Organization Name, "Article or Page Title", accessed [Month Day, Year], URL [^2]: Author/Organization Name, "Article or Page Title", accessed [Month Day, Year], URL Example: ## References [^1]: Anthropic, "Introducing Contextual Retrieval", accessed September 2024, https://www.anthropic.com/news/contextual-retrieval [^2]: HashiCorp, "Vault Dynamic Secrets", accessed October 2025, https://www.vaultproject.io/docs/secrets/dynamic Critical rules: - Every footnote number used in the text must have a corresponding entry in this section - Entries must be in numerical order without gaps - Each entry must include: source name, article title in quotes, access date, and full URL - URLs must be complete and clickable (include https://) - If the exact access date is unknown, use the publication date or current date </references_section_format> <quality_checks> Before delivering research artifact, verify: - Every factual claim has a footnote marker - All footnote numbers in text have matching entries in References section - No footnote numbers are skipped (1, 2, 3... not 1, 3, 5...) - All URLs are complete and properly formatted - The References section appears at the very end of the document </quality_checks> </citation_requirements> <examples> <example type="market_analysis"> Good: "HashiCorp Vault is a powerful, open-source tool for secrets management, encryption as a service, and privileged access management.[^1] Its core capabilities include secure secret storage, dynamic secrets generation, and data encryption.[^1] Dynamic secrets are a key differentiator - Vault can generate credentials on-demand for systems like AWS and databases, which are short-lived and automatically revoked after their lease expires.[^2]" References: [^1]: HashiCorp, "What is Vault?", accessed October 9, 2025, https://www.vaultproject.io/docs/what-is-vault [^2]: HashiCorp, "Dynamic Secrets", accessed October 9, 2025, https://www.vaultproject.io/docs/secrets/dynamic Bad: "HashiCorp Vault is a powerful secrets management tool. It has many features including dynamic secrets, encryption, and access control." [NO CITATIONS] </example> <example type="technology_recommendation"> Good: "For the backend services, Go (Golang) is highly recommended for its excellent performance, low memory footprint, and built-in concurrency primitives.[^1] Go is particularly well-suited for high-throughput microservices and CLI tools.[^2] Example of a simple HTTP server in Go: ```go package main import ( "fmt" "net/http" ) func handler(w http.ResponseWriter, r *http.Request) { fmt.Fprintf(w, "Hello, World!") } func main() { http.HandleFunc("/", handler) http.ListenAndServe(":8080", nil) } ``` Trade-offs: While Go offers superior performance, teams already experienced with Python or Node.js may face a learning curve.[^3]" References: [^1]: Go Project, "Why Go", accessed October 9, 2025, https://go.dev/solutions/ [^2]: CNCF, "Cloud Native Landscape - Go Projects", accessed October 9, 2025, https://landscape.cncf.io/ [^3]: Stack Overflow, "Developer Survey 2024 - Language Preferences", accessed October 9, 2025, https://survey.stackoverflow.co/2024 Bad: "Use Go for the backend because it's fast and modern." [NO JUSTIFICATION, NO CITATIONS, NO EXAMPLES] </example> <example type="gap_analysis"> Good: "**Integration Gap**: While both Doppler and Infisical offer extensive cloud provider integrations, neither provides native integration with HashiCorp Nomad for secret injection.[^1][^2] This creates friction for teams using Nomad as their orchestration platform, forcing them to use Vault directly or build custom integration layers. This gap represents an opportunity to provide first-class Nomad support, potentially through a Nomad task driver plugin.[^3]" References: [^1]: Doppler, "Integrations Documentation", accessed October 9, 2025, https://docs.doppler.com/docs/integrations [^2]: Infisical, "Integrations", accessed October 9, 2025, https://infisical.com/docs/integrations/overview [^3]: HashiCorp, "Nomad Task Drivers", accessed October 9, 2025, https://developer.hashicorp.com/nomad/docs/drivers Bad: "There's a gap in Nomad integration that we could fill." [NO EVIDENCE, NO CITATIONS, NO DETAILS] </example> </examples> <product_category_guidance> <appendix_section> Include product-specific guidance based on category. Add as appendix to research artifact if applicable: **For CLI Tools:** - CLI design patterns and user experience best practices - Argument parsing libraries and conventions - Output formatting (human-readable vs machine-readable) - Configuration file patterns (.rc files, YAML, TOML) - Shell integration (completions, aliases) - Distribution and installation methods **For SaaS Platforms:** - Multi-tenancy architecture patterns - Subscription and billing integration - Admin dashboard and user management - API rate limiting and quotas - Data residency and compliance considerations - Customer onboarding and activation flows **For Infrastructure Tools:** - Infrastructure as Code (IaC) patterns - State management and drift detection - Provider plugin architecture - High availability and disaster recovery - Upgrade and migration strategies - Operational runbooks and incident response **For AI/ML Products:** - Model serving and inference architecture - Feature store and data pipeline design - Model versioning and experiment tracking - A/B testing and gradual rollout - Explainability and bias detection - Prompt engineering and context management - Vector database and RAG architecture - LLM provider integration patterns </appendix_section> </product_category_guidance> </generator_prompt>