523 lines
15 KiB
Markdown
523 lines
15 KiB
Markdown
# BMAD Memory Integration Patterns
|
|
|
|
## Overview
|
|
|
|
This guide provides proven patterns for integrating the BMAD Memory Architecture into different workflows and AI environments. These patterns ensure consistent, effective memory usage across various scenarios.
|
|
|
|
## Core Integration Patterns
|
|
|
|
### Pattern 1: Conversation Initialization
|
|
|
|
**Purpose:** Establish memory context at the start of each conversation
|
|
|
|
**Implementation:**
|
|
```markdown
|
|
# Standard Memory Initialization
|
|
At conversation start, use this pattern:
|
|
|
|
"Loading BMAD Memory System...
|
|
|
|
/memory-status
|
|
/recall-recent 5
|
|
/load-context [project_name]
|
|
|
|
Based on previous memories, I see we were working on [summary of recent context].
|
|
Ready to continue with memory-enhanced assistance."
|
|
```
|
|
|
|
**Example:**
|
|
```
|
|
User: "Let's continue working on the e-commerce project"
|
|
|
|
AI: "Loading BMAD Memory System...
|
|
|
|
/memory-status
|
|
Found 23 memories (8 decisions, 12 solutions, 3 patterns)
|
|
|
|
/recall-recent 5
|
|
mem_018: API rate limiting implementation
|
|
mem_017: PostgreSQL schema design
|
|
mem_016: React component structure
|
|
mem_015: Authentication flow decision
|
|
mem_014: Payment gateway integration
|
|
|
|
Based on previous memories, I see we were working on the API implementation and decided to use PostgreSQL with JWT authentication. Ready to continue with memory-enhanced assistance."
|
|
```
|
|
|
|
### Pattern 2: Decision Documentation
|
|
|
|
**Purpose:** Automatically capture and contextualize important decisions
|
|
|
|
**Implementation:**
|
|
```markdown
|
|
# Decision Capture Pattern
|
|
When decisions are made:
|
|
|
|
1. Detect decision language
|
|
2. Extract decision content
|
|
3. Capture alternatives considered
|
|
4. Document rationale
|
|
5. Link to related memories
|
|
6. Set appropriate importance
|
|
|
|
Trigger phrases:
|
|
- "I've decided to..."
|
|
- "We'll go with..."
|
|
- "The choice is..."
|
|
- "After considering options..."
|
|
```
|
|
|
|
**Example:**
|
|
```
|
|
User: "After considering the options, I've decided to use Next.js instead of plain React because we need SSR for SEO"
|
|
|
|
AI: "I've decided to use Next.js instead of plain React because we need SSR for SEO
|
|
|
|
[AUTO-CREATED] mem_019: DECISION - Frontend Framework Choice
|
|
Content: Use Next.js instead of plain React for SSR and SEO benefits
|
|
Alternatives: Plain React, Gatsby, Nuxt.js
|
|
Rationale: Server-side rendering needed for SEO
|
|
Importance: 0.8
|
|
Tags: frontend, nextjs, ssr, seo, architecture
|
|
|
|
/relate mem_019 "supports" mem_012 0.7 # Links to previous frontend architecture memory
|
|
|
|
This decision will influence our deployment strategy and component structure. Should I update our architecture documentation?"
|
|
```
|
|
|
|
### Pattern 3: Problem-Solution Tracking
|
|
|
|
**Purpose:** Track problems and their solutions for future reference
|
|
|
|
**Implementation:**
|
|
```markdown
|
|
# Problem-Solution Pattern
|
|
When problems arise:
|
|
|
|
1. Create WORKING memory for problem
|
|
2. Track solution attempts
|
|
3. Document successful solution
|
|
4. Create PATTERN memory if reusable
|
|
5. Link problem to solution
|
|
|
|
Workflow:
|
|
Problem identified Working memory created
|
|
Solution attempts Update working memory
|
|
Solution found Create SOLUTION memory
|
|
Pattern emerges Create PATTERN memory
|
|
```
|
|
|
|
**Example:**
|
|
```
|
|
User: "I'm getting CORS errors when calling the API from the frontend"
|
|
|
|
AI: "The problem is: CORS errors when calling API from frontend
|
|
|
|
[AUTO-CREATED] mem_020: WORKING - CORS Error Investigation
|
|
Content: Frontend getting CORS errors when calling API
|
|
Context: Development environment, React frontend, Node.js API
|
|
Tags: cors, api, frontend, debugging
|
|
Importance: 0.6
|
|
|
|
Let me help you solve this. Have you configured CORS middleware on your API server?"
|
|
|
|
User: "No, I haven't set up CORS middleware"
|
|
|
|
AI: "The solution is: Configure CORS middleware on the API server
|
|
|
|
[AUTO-CREATED] mem_021: SOLUTION - CORS Configuration
|
|
Content: Add CORS middleware to Node.js API server to allow frontend requests
|
|
Steps: 1. Install cors package, 2. Configure allowed origins, 3. Add middleware to Express app
|
|
Code: app.use(cors({ origin: 'http://localhost:3000' }))
|
|
Tags: cors, api, middleware, solution
|
|
Importance: 0.7
|
|
|
|
/relate mem_021 "solves" mem_020 0.9
|
|
/update-memory mem_020 status:"resolved"
|
|
|
|
This is a common pattern for API development. Should I create a reusable pattern memory?"
|
|
```
|
|
|
|
### Pattern 4: Knowledge Accumulation
|
|
|
|
**Purpose:** Build up domain knowledge over time
|
|
|
|
**Implementation:**
|
|
```markdown
|
|
# Knowledge Building Pattern
|
|
As conversations progress:
|
|
|
|
1. Extract key concepts and facts
|
|
2. Create SEMANTIC memories for important knowledge
|
|
3. Link related concepts
|
|
4. Build knowledge graphs
|
|
5. Reference accumulated knowledge in responses
|
|
|
|
Knowledge triggers:
|
|
- "This means..."
|
|
- "The key insight is..."
|
|
- "I learned that..."
|
|
- "It's important to understand..."
|
|
```
|
|
|
|
**Example:**
|
|
```
|
|
User: "I learned that React 18's concurrent features can help with performance, but they require careful state management"
|
|
|
|
AI: "I learned that React 18's concurrent features can help with performance, but they require careful state management
|
|
|
|
[AUTO-CREATED] mem_022: LEARNING - React 18 Concurrent Features
|
|
Content: React 18 concurrent features improve performance but need careful state management
|
|
Details: Concurrent rendering can interrupt and resume work, requires understanding of state updates and effects
|
|
Implications: Need to review existing components for concurrent compatibility
|
|
Tags: react18, concurrent, performance, state-management
|
|
Importance: 0.7
|
|
|
|
/relate mem_022 "relates_to" mem_016 0.8 # Links to React component structure memory
|
|
|
|
This knowledge will be valuable when we optimize our React components. I'll reference this when discussing performance improvements."
|
|
```
|
|
|
|
### Pattern 5: Context Preservation
|
|
|
|
**Purpose:** Maintain context across conversation sessions
|
|
|
|
**Implementation:**
|
|
```markdown
|
|
# Context Preservation Pattern
|
|
At session end:
|
|
|
|
1. Summarize key session outcomes
|
|
2. Create session memory
|
|
3. Update working memories
|
|
4. Preserve important context
|
|
5. Set up for next session
|
|
|
|
At session start:
|
|
1. Load previous session context
|
|
2. Restore working memories
|
|
3. Continue from where left off
|
|
```
|
|
|
|
**Example:**
|
|
```
|
|
# End of session
|
|
AI: "Session Summary - E-commerce Project Progress
|
|
|
|
[AUTO-CREATED] mem_023: WORKING - Session 2024-01-15 Summary
|
|
Content: Completed API authentication design, decided on JWT tokens, started database schema planning
|
|
Next steps: Finalize user table structure, implement password hashing, set up development environment
|
|
Active issues: None
|
|
Decisions made: JWT authentication, PostgreSQL database
|
|
Tags: session-summary, progress, authentication, database
|
|
Importance: 0.6
|
|
|
|
/update-memory mem_015 status:"implemented" # Update auth flow memory
|
|
/create-working "Next session: Continue database schema design" 0.5
|
|
|
|
Ready for next session. I'll remember our progress and continue from database schema design."
|
|
|
|
# Start of next session
|
|
AI: "Welcome back! Loading previous session context...
|
|
|
|
/recall tag:session-summary recent:1
|
|
Found session summary from 2024-01-15
|
|
|
|
/recall status:active
|
|
Found 2 active working memories
|
|
|
|
We were working on the e-commerce project and had completed API authentication design with JWT tokens. Next step was to finalize the database schema. Ready to continue?"
|
|
```
|
|
|
|
## Environment-Specific Patterns
|
|
|
|
### Claude Code Integration Pattern
|
|
|
|
```markdown
|
|
# Claude Code Memory Pattern
|
|
Optimized for conversation-based development:
|
|
|
|
1. File-based memory storage
|
|
2. Code context integration
|
|
3. Conversation continuity
|
|
4. Simple command interface
|
|
|
|
Implementation:
|
|
- Store memories in project .bmad-memory/ folder
|
|
- Reference code files in memory metadata
|
|
- Use conversation context for immediate access
|
|
- Provide file export for persistence
|
|
```
|
|
|
|
**Example:**
|
|
```
|
|
User: "Let's work on the user authentication component"
|
|
|
|
AI: "/recall 'authentication' AND tag:component
|
|
|
|
Found relevant memories:
|
|
- mem_015: JWT authentication flow decision
|
|
- mem_021: CORS configuration solution
|
|
- mem_018: Password hashing pattern
|
|
|
|
Based on these memories, I'll help you build an authentication component that uses JWT tokens with proper CORS handling and secure password hashing.
|
|
|
|
/remember "Working on user authentication component in src/components/Auth.tsx" WORKING 0.5
|
|
|
|
Let's start with the component structure..."
|
|
```
|
|
|
|
### V0 Integration Pattern
|
|
|
|
```markdown
|
|
# V0 Memory Pattern
|
|
Optimized for component generation:
|
|
|
|
1. Design pattern memory
|
|
2. Component library tracking
|
|
3. User preference learning
|
|
4. Generation history
|
|
|
|
Implementation:
|
|
- Remember design preferences
|
|
- Track successful component patterns
|
|
- Learn from user feedback
|
|
- Build component knowledge base
|
|
```
|
|
|
|
**Example:**
|
|
```
|
|
User: "Create a login form component"
|
|
|
|
AI: "/recall 'login' OR 'form' OR 'authentication'
|
|
|
|
Found design patterns:
|
|
- mem_025: Form validation pattern with Formik
|
|
- mem_018: Authentication flow with JWT
|
|
- mem_030: Design system color palette
|
|
- mem_028: Responsive form layout pattern
|
|
|
|
Based on your previous preferences, I'll create a login form with:
|
|
- Tailwind CSS styling using your color palette
|
|
- Formik for form handling and validation
|
|
- Responsive design for mobile/desktop
|
|
- JWT authentication integration
|
|
|
|
/remember 'Generated login form component with Formik validation and responsive design' PATTERN 0.7
|
|
|
|
[Generates component code]"
|
|
```
|
|
|
|
### Cursor AI Integration Pattern
|
|
|
|
```markdown
|
|
# Cursor AI Memory Pattern
|
|
Optimized for IDE integration:
|
|
|
|
1. Code context awareness
|
|
2. File-based memory storage
|
|
3. Workspace integration
|
|
4. Real-time memory updates
|
|
|
|
Implementation:
|
|
- Track code changes and decisions
|
|
- Remember refactoring patterns
|
|
- Store debugging solutions
|
|
- Integrate with workspace context
|
|
```
|
|
|
|
**Example:**
|
|
```
|
|
User: [Selects code block with authentication logic]
|
|
|
|
AI: "/recall-context file:auth.js
|
|
|
|
Found related memories:
|
|
- mem_021: JWT token validation pattern
|
|
- mem_033: Error handling for auth failures
|
|
- mem_027: Session management approach
|
|
|
|
I see you're working on authentication logic. Based on previous patterns, I recommend:
|
|
1. Using the JWT validation pattern from mem_021
|
|
2. Implementing error handling from mem_033
|
|
3. Following session management from mem_027
|
|
|
|
/remember 'Refactored authentication logic in auth.js using established patterns' SOLUTION 0.6
|
|
|
|
Would you like me to suggest specific improvements based on these patterns?"
|
|
```
|
|
|
|
## Advanced Integration Patterns
|
|
|
|
### Pattern 6: Cross-Session Learning
|
|
|
|
**Purpose:** Learn and improve across multiple sessions
|
|
|
|
**Implementation:**
|
|
```markdown
|
|
# Cross-Session Learning Pattern
|
|
Track patterns across sessions:
|
|
|
|
1. Identify recurring themes
|
|
2. Extract successful approaches
|
|
3. Learn from mistakes
|
|
4. Build expertise over time
|
|
5. Adapt recommendations
|
|
|
|
Learning indicators:
|
|
- Repeated similar problems
|
|
- Successful solution patterns
|
|
- User feedback and corrections
|
|
- Performance improvements
|
|
```
|
|
|
|
**Example:**
|
|
```
|
|
AI: "I notice this is the third time we've discussed API rate limiting. Let me check our previous approaches...
|
|
|
|
/recall 'rate limiting' type:SOLUTION
|
|
|
|
Found 3 previous solutions:
|
|
- mem_018: Express rate-limit middleware (successful)
|
|
- mem_025: Redis-based rate limiting (complex, abandoned)
|
|
- mem_031: Nginx rate limiting (production solution)
|
|
|
|
Pattern emerging: You prefer simple middleware solutions for development, more robust solutions for production.
|
|
|
|
/remember 'User prefers simple rate limiting for dev, robust for production' PATTERN 0.8
|
|
|
|
Based on this pattern, I recommend starting with express-rate-limit for development and planning Nginx rate limiting for production."
|
|
```
|
|
|
|
### Pattern 7: Collaborative Memory
|
|
|
|
**Purpose:** Share memory across team members
|
|
|
|
**Implementation:**
|
|
```markdown
|
|
# Collaborative Memory Pattern
|
|
Enable team knowledge sharing:
|
|
|
|
1. Tag memories by team member
|
|
2. Share decision rationales
|
|
3. Document team agreements
|
|
4. Track collective learning
|
|
5. Maintain team context
|
|
|
|
Team memory structure:
|
|
- Individual memories (private)
|
|
- Team memories (shared)
|
|
- Project memories (persistent)
|
|
- Organizational memories (long-term)
|
|
```
|
|
|
|
**Example:**
|
|
```
|
|
User: "The team decided to use microservices architecture"
|
|
|
|
AI: "The team decided to use microservices architecture
|
|
|
|
[AUTO-CREATED] mem_035: DECISION - Microservices Architecture (TEAM)
|
|
Content: Team decision to adopt microservices architecture
|
|
Participants: [team members if specified]
|
|
Rationale: [to be filled based on discussion]
|
|
Impact: High - affects entire system design
|
|
Tags: architecture, microservices, team-decision
|
|
Visibility: team
|
|
Importance: 0.9
|
|
|
|
This is a significant architectural decision. Should I document the rationale and alternatives considered for the team?"
|
|
```
|
|
|
|
### Pattern 8: Memory-Driven Recommendations
|
|
|
|
**Purpose:** Use accumulated memory to provide intelligent recommendations
|
|
|
|
**Implementation:**
|
|
```markdown
|
|
# Recommendation Pattern
|
|
Leverage memory for suggestions:
|
|
|
|
1. Analyze current context
|
|
2. Find relevant past experiences
|
|
3. Identify successful patterns
|
|
4. Suggest proven approaches
|
|
5. Warn about past issues
|
|
|
|
Recommendation triggers:
|
|
- Similar contexts to past problems
|
|
- Opportunities to apply patterns
|
|
- Potential issues based on history
|
|
- Optimization opportunities
|
|
```
|
|
|
|
**Example:**
|
|
```
|
|
User: "I need to implement user notifications"
|
|
|
|
AI: "/recall 'notifications' OR 'messaging' OR 'alerts'
|
|
|
|
Found relevant experiences:
|
|
- mem_028: Email notifications with SendGrid (successful)
|
|
- mem_032: Push notifications implementation (complex)
|
|
- mem_036: Real-time notifications with WebSockets (performance issues)
|
|
|
|
Based on your previous experiences:
|
|
|
|
Recommended: Start with email notifications using SendGrid (proven successful)
|
|
Consider carefully: Push notifications (added complexity)
|
|
Avoid initially: WebSockets for notifications (had performance issues)
|
|
|
|
/remember 'Recommended email notifications first based on previous success with SendGrid' PATTERN 0.7
|
|
|
|
Would you like me to help implement email notifications using the successful pattern from mem_028?"
|
|
```
|
|
|
|
## Memory Quality Patterns
|
|
|
|
### Pattern 9: Memory Validation
|
|
|
|
**Purpose:** Ensure memory quality and accuracy
|
|
|
|
**Implementation:**
|
|
```markdown
|
|
# Memory Validation Pattern
|
|
Maintain memory quality:
|
|
|
|
1. Validate memory content
|
|
2. Check for duplicates
|
|
3. Verify relationships
|
|
4. Update outdated information
|
|
5. Remove obsolete memories
|
|
|
|
Validation triggers:
|
|
- Contradictory information
|
|
- Outdated technology references
|
|
- Broken relationships
|
|
- Low-quality content
|
|
```
|
|
|
|
### Pattern 10: Memory Evolution
|
|
|
|
**Purpose:** Evolve memories as understanding improves
|
|
|
|
**Implementation:**
|
|
```markdown
|
|
# Memory Evolution Pattern
|
|
Update memories as knowledge grows:
|
|
|
|
1. Refine understanding over time
|
|
2. Update importance scores
|
|
3. Add new relationships
|
|
4. Consolidate related memories
|
|
5. Archive obsolete information
|
|
|
|
Evolution triggers:
|
|
- New information contradicts old
|
|
- Better understanding emerges
|
|
- Technology changes
|
|
- Requirements evolve
|
|
```
|
|
|
|
These integration patterns ensure that the BMAD Memory Architecture enhances rather than complicates your AI interactions, providing intelligent, context-aware assistance that improves over time.
|