146 lines
5.4 KiB
Markdown
146 lines
5.4 KiB
Markdown
# Memory Synthesis Task
|
|
|
|
## Purpose
|
|
Extract and synthesize learnings from development work into persistent project memory for future reference and continuous improvement.
|
|
|
|
## When to Use
|
|
This task should be executed:
|
|
- At the completion of every story implementation
|
|
- When manually triggered via `*mem-synth` orchestrator command
|
|
- When adding specific memories via `*mem-add` orchestrator command
|
|
|
|
## Process
|
|
|
|
### Section 1: Memory Synthesizer Activation
|
|
|
|
1. **Activate Memory Synthesizer Persona**:
|
|
- Switch to "Memory Synthesizer" role for objective analysis
|
|
- Focus on extracting generalizable learnings rather than specific implementation details
|
|
|
|
### Section 2: Knowledge Extraction (Two-Pass Analysis)
|
|
|
|
2. **First Pass - Explicit Learnings**:
|
|
- Scan all `Dev Notes` sections in the story file
|
|
- Look for explicit lessons learned, patterns discovered, or insights documented
|
|
- Extract formal review summaries and their conclusions
|
|
- Identify documented anti-patterns or best practices
|
|
|
|
3. **Second Pass - Implicit Learnings**:
|
|
- Analyze implementation decisions and their outcomes
|
|
- Identify patterns in complexity assessments and review failures
|
|
- Extract insights from dependency analysis and version considerations
|
|
- Note architectural decisions and their rationale
|
|
|
|
### Section 3: Memory Validation & Synthesis
|
|
|
|
4. **Memory Candidate Generation**:
|
|
- Transform specific learnings into generalizable principles
|
|
- Focus on actionable insights that apply beyond the current story
|
|
- Ensure memories are concise but comprehensive
|
|
- Format as clear, actionable statements
|
|
|
|
5. **Conflict Detection & Validation**:
|
|
- Load existing project memory from `.bmad-core/data/bmad-project-memory.md`
|
|
- Check each memory candidate against existing memories
|
|
- Identify potential conflicts or contradictions
|
|
- Resolve conflicts by:
|
|
- Updating existing memory with new insights
|
|
- Creating more nuanced memory that encompasses both perspectives
|
|
- Flagging genuine contradictions for user review
|
|
|
|
6. **Memory Quality Assessment**:
|
|
- Ensure memories are:
|
|
- **Specific enough** to be actionable
|
|
- **General enough** to apply to future work
|
|
- **Clear and unambiguous** in their guidance
|
|
- **Non-contradictory** with existing project knowledge
|
|
|
|
### Section 4: Memory Integration
|
|
|
|
7. **Memory File Update**:
|
|
- Append validated new memories to the project memory file
|
|
- Maintain chronological order with clear attribution
|
|
- Use consistent formatting for easy parsing
|
|
- Preserve existing memory structure and organization
|
|
|
|
8. **Integration Verification**:
|
|
- Verify the updated memory file is well-formed
|
|
- Ensure no duplicate or contradictory entries exist
|
|
- Confirm all new memories are properly integrated
|
|
|
|
## Memory Quality Standards
|
|
|
|
### Good Memory Examples
|
|
- "Authentication logic should be centralized in the auth service; direct token manipulation is an anti-pattern in this codebase"
|
|
- "Always validate user inputs before database queries to prevent SQL injection vulnerabilities"
|
|
- "Complex UI components (Fibonacci 5+) should include unit tests for state management logic"
|
|
|
|
### Poor Memory Examples (Too Specific)
|
|
- "The login button should be blue" (too specific to one implementation)
|
|
- "Use React 18.2.0 for this project" (version-specific, not generalizable)
|
|
- "File UserService.ts needs refactoring" (specific file reference)
|
|
|
|
### Memory Conflict Resolution
|
|
|
|
**Duplicate Detection**:
|
|
- Identify memories that convey the same principle
|
|
- Merge similar memories into more comprehensive statements
|
|
- Preserve the most actionable version
|
|
|
|
**Contradiction Handling**:
|
|
- Flag genuine contradictions for user review
|
|
- Provide context for conflicting approaches
|
|
- Suggest resolution strategies when possible
|
|
|
|
**Memory Evolution**:
|
|
- Update existing memories with new insights
|
|
- Refine general principles based on specific experiences
|
|
- Maintain memory relevance and accuracy
|
|
|
|
## Output Format
|
|
|
|
### Memory File Structure
|
|
```markdown
|
|
# Project Memory
|
|
|
|
## Development Patterns
|
|
- [Memory about coding patterns and practices]
|
|
|
|
## Architecture Decisions
|
|
- [Memory about architectural choices and rationale]
|
|
|
|
## Quality Standards
|
|
- [Memory about testing, review, and quality practices]
|
|
|
|
## Technology Insights
|
|
- [Memory about specific technologies, libraries, and tools]
|
|
|
|
## Process Learnings
|
|
- [Memory about development process and workflow insights]
|
|
```
|
|
|
|
### Memory Entry Format
|
|
```markdown
|
|
- **[Category]**: [Actionable memory statement] (Source: Story [ID], [Date])
|
|
```
|
|
|
|
## Error Handling
|
|
|
|
### Memory Validation Failures
|
|
- **Duplicate**: "I've already got this noted, great minds think alike!"
|
|
- **Contradiction**: "Hmm, this conflicts with what I learned in Story X. Want to discuss which approach is better?"
|
|
- **Invalid**: "This seems too specific to generalize. Could you rephrase it as a broader principle?"
|
|
- **Success**: "Great insight! I've added this to our project memory."
|
|
|
|
### File Access Issues
|
|
- Gracefully handle missing memory file (create new one)
|
|
- Handle file permission issues with clear error messages
|
|
- Provide fallback options when file operations fail
|
|
|
|
## Dependencies
|
|
|
|
- Access to story file with Dev Notes sections
|
|
- Read/write access to `.bmad-core/data/bmad-project-memory.md`
|
|
- Understanding of project context and patterns
|
|
- Ability to perform semantic analysis of development notes
|