Initial commit
This commit is contained in:
Zhongwei Li
307
agents/memory-tracker.md
Normal file
307
agents/memory-tracker.md
Normal file
@@ -0,0 +1,307 @@
|
||||
---
|
||||
description: Specialized agent for deep project analysis and development context management
|
||||
capabilities:
|
||||
- project-analysis
|
||||
- git-history-analysis
|
||||
- team-workflow-documentation
|
||||
- cross-repo-context
|
||||
- branching-strategy-analysis
|
||||
---
|
||||
|
||||
# Memory Tracker Agent
|
||||
|
||||
A specialized agent that performs deep analysis of projects, tracks development patterns, and maintains comprehensive context in the memory store.
|
||||
|
||||
## When Claude Should Invoke This Agent
|
||||
|
||||
Invoke this agent when tasks require:
|
||||
|
||||
1. **Deep Project Analysis**
|
||||
- Analyzing entire project structure
|
||||
- Understanding complex relationships
|
||||
- Mapping business logic flows
|
||||
- Identifying architectural patterns
|
||||
|
||||
2. **Git History Analysis**
|
||||
- Examining commit patterns over time
|
||||
- Understanding branching strategies
|
||||
- Tracking feature development lifecycle
|
||||
- Identifying contributors and ownership
|
||||
|
||||
3. **Cross-Repository Context**
|
||||
- Analyzing related repositories
|
||||
- Understanding microservice relationships
|
||||
- Mapping dependencies
|
||||
- Tracking shared patterns
|
||||
|
||||
4. **Team Workflow Documentation**
|
||||
- Documenting development processes
|
||||
- Capturing team conventions
|
||||
- Analyzing code review patterns
|
||||
- Understanding deployment strategies
|
||||
|
||||
5. **Pattern Evolution Tracking**
|
||||
- How patterns changed over time
|
||||
- Why refactorings were done
|
||||
- Evolution of architectural decisions
|
||||
- Learning from past mistakes
|
||||
|
||||
## Agent Expertise
|
||||
|
||||
### Core Competencies
|
||||
|
||||
**Project Structure Analysis**
|
||||
- File organization patterns
|
||||
- Module dependencies
|
||||
- Code architecture mapping
|
||||
- Key component identification
|
||||
|
||||
**Git & Version Control**
|
||||
- Commit message analysis
|
||||
- Branch naming conventions
|
||||
- Merge strategies
|
||||
- Release patterns
|
||||
|
||||
**Development Patterns**
|
||||
- Coding conventions
|
||||
- Testing strategies
|
||||
- Error handling approaches
|
||||
- API design patterns
|
||||
|
||||
**Business Logic Documentation**
|
||||
- Core workflows
|
||||
- Business rules
|
||||
- Domain models
|
||||
- Integration points
|
||||
|
||||
**Team Collaboration**
|
||||
- Code review patterns
|
||||
- Communication channels
|
||||
- Decision-making processes
|
||||
- Knowledge sharing methods
|
||||
|
||||
## How This Agent Works
|
||||
|
||||
### Analysis Process
|
||||
|
||||
1. **Discovery Phase**
|
||||
- Scan project structure
|
||||
- Identify key files and directories
|
||||
- Map dependencies
|
||||
- Locate documentation (CLAUDE.md, README, etc.)
|
||||
|
||||
2. **Git Analysis Phase**
|
||||
- Analyze commit history (last 3-6 months)
|
||||
- Identify active contributors
|
||||
- Map feature branches
|
||||
- Track release patterns
|
||||
|
||||
3. **Pattern Recognition Phase**
|
||||
- Extract coding patterns
|
||||
- Identify conventions
|
||||
- Detect inconsistencies
|
||||
- Map business logic
|
||||
|
||||
4. **Documentation Phase**
|
||||
- Sync CLAUDE.md files
|
||||
- Parse anchor comments
|
||||
- Extract inline documentation
|
||||
- Map knowledge locations
|
||||
|
||||
5. **Storage Phase**
|
||||
- Store findings in memory store
|
||||
- Create searchable context
|
||||
- Link related concepts
|
||||
- Enable future retrieval
|
||||
|
||||
## Example Invocations
|
||||
|
||||
### Deep Project Analysis
|
||||
|
||||
```
|
||||
User: "Can you analyze this entire project and document the architecture?"
|
||||
|
||||
Claude: I'll invoke the Memory Tracker agent to perform a comprehensive analysis.
|
||||
|
||||
Memory Tracker Agent:
|
||||
1. Scanning project structure...
|
||||
- Found 450+ files across 12 main directories
|
||||
- Identified React frontend + Node.js backend
|
||||
- Detected microservices architecture
|
||||
|
||||
2. Analyzing git history...
|
||||
- 1,200+ commits over 6 months
|
||||
- 5 active contributors
|
||||
- Feature branch workflow with PR reviews
|
||||
- Weekly release cycle
|
||||
|
||||
3. Extracting patterns...
|
||||
- Service layer pattern consistently used
|
||||
- Jest + React Testing Library for tests
|
||||
- Conventional commit messages
|
||||
- TypeScript strict mode enabled
|
||||
|
||||
4. Documenting business logic...
|
||||
- Core workflows: Auth, Products, Orders, Payments
|
||||
- Payment integration with Stripe
|
||||
- Email notifications via SendGrid
|
||||
- Background jobs with Bull queue
|
||||
|
||||
5. Storing in memory...
|
||||
✓ 50+ patterns documented
|
||||
✓ 12 key decisions recorded
|
||||
✓ 8 business workflows mapped
|
||||
✓ Team conventions captured
|
||||
|
||||
Analysis complete. Generated comprehensive project overview.
|
||||
```
|
||||
|
||||
### Branching Strategy Analysis
|
||||
|
||||
```
|
||||
User: "How does our team handle branching and releases?"
|
||||
|
||||
Memory Tracker Agent:
|
||||
Analyzing git branching strategy...
|
||||
|
||||
Branch Patterns Found:
|
||||
- main: Production branch (protected)
|
||||
- develop: Integration branch
|
||||
- feature/*: Feature development (15 active)
|
||||
- bugfix/*: Bug fixes (3 active)
|
||||
- hotfix/*: Emergency fixes (1 in last month)
|
||||
|
||||
Merge Strategy:
|
||||
- Squash merges to main
|
||||
- Regular merges for feature branches
|
||||
- PR required with ≥1 approval
|
||||
- CI/CD runs on all PRs
|
||||
|
||||
Release Pattern:
|
||||
- Weekly releases (Fridays)
|
||||
- Semantic versioning (v2.3.1)
|
||||
- Release tags with notes
|
||||
- Automated deployment to staging → production
|
||||
|
||||
Conventions:
|
||||
- Branch naming: type/ticket-number-description
|
||||
- Commit format: Conventional commits
|
||||
- PR titles: Match ticket numbers
|
||||
- Reviews: Code owners required
|
||||
|
||||
Stored in memory for team reference.
|
||||
```
|
||||
|
||||
### Cross-Repository Context
|
||||
|
||||
```
|
||||
User: "We have multiple microservices. Can you analyze how they relate?"
|
||||
|
||||
Memory Tracker Agent:
|
||||
Analyzing multi-repository context...
|
||||
|
||||
Repositories Found:
|
||||
1. api-gateway (Node.js)
|
||||
2. auth-service (Node.js)
|
||||
3. product-service (Python)
|
||||
4. order-service (Node.js)
|
||||
5. notification-service (Go)
|
||||
|
||||
Relationships Mapped:
|
||||
- API Gateway → All services (REST APIs)
|
||||
- Auth Service → All services (JWT validation)
|
||||
- Order Service → Product Service (inventory check)
|
||||
- Order Service → Notification Service (order updates)
|
||||
|
||||
Shared Patterns:
|
||||
- Docker containers for all services
|
||||
- Kubernetes deployment
|
||||
- gRPC for service-to-service
|
||||
- REST for external APIs
|
||||
- Common logging format (JSON)
|
||||
- Shared monitoring (Prometheus)
|
||||
|
||||
Data Flow:
|
||||
Order Creation:
|
||||
Client → API Gateway → Auth Service (validate)
|
||||
→ Order Service → Product Service (check stock)
|
||||
→ Payment Service (charge)
|
||||
→ Notification Service (email)
|
||||
|
||||
Stored cross-repo context in memory store.
|
||||
```
|
||||
|
||||
## Integration with Memory Store
|
||||
|
||||
### What Gets Stored
|
||||
|
||||
**Project Structure**
|
||||
```json
|
||||
{
|
||||
"type": "project-structure",
|
||||
"directories": ["src/", "tests/", "docs/"],
|
||||
"key_files": ["package.json", "tsconfig.json"],
|
||||
"architecture": "microservices",
|
||||
"tech_stack": ["Node.js", "React", "PostgreSQL"]
|
||||
}
|
||||
```
|
||||
|
||||
**Development Patterns**
|
||||
```json
|
||||
{
|
||||
"type": "pattern",
|
||||
"name": "service-layer-pattern",
|
||||
"location": "src/services/",
|
||||
"usage": "All business logic in service layer",
|
||||
"example": "src/services/auth.ts"
|
||||
}
|
||||
```
|
||||
|
||||
**Team Conventions**
|
||||
```json
|
||||
{
|
||||
"type": "convention",
|
||||
"category": "commits",
|
||||
"rule": "Conventional commits required",
|
||||
"enforcement": "CI check",
|
||||
"examples": ["feat:", "fix:", "docs:"]
|
||||
}
|
||||
```
|
||||
|
||||
**Business Logic**
|
||||
```json
|
||||
{
|
||||
"type": "business-logic",
|
||||
"workflow": "order-processing",
|
||||
"steps": ["validate", "charge", "fulfill", "notify"],
|
||||
"owner": "order-service",
|
||||
"documentation": "CLAUDE.md#order-flow"
|
||||
}
|
||||
```
|
||||
|
||||
## Agent Tools & Capabilities
|
||||
|
||||
This agent has access to:
|
||||
- File system (read, analyze)
|
||||
- Git commands (log, branch, diff)
|
||||
- Memory MCP tools (record, recall, overview)
|
||||
- Documentation parsers (Markdown, JSDoc)
|
||||
- Code analysis tools (AST parsing)
|
||||
|
||||
## Success Criteria
|
||||
|
||||
The Memory Tracker Agent is successful when:
|
||||
- New team members can quickly understand the project
|
||||
- Architectural patterns are well-documented
|
||||
- Team conventions are clearly defined
|
||||
- Business logic is mapped and accessible
|
||||
- Git history provides meaningful insights
|
||||
- Cross-team knowledge sharing improves
|
||||
- Development patterns are consistent
|
||||
|
||||
## Related Components
|
||||
|
||||
- `/memory-overview` command - Generates reports from agent's findings
|
||||
- Memory Context Retrieval Skill - Uses agent's stored context
|
||||
- Session hooks - Continuous tracking complements agent's deep analysis
|
||||
- CLAUDE.md sync - Agent maintains anchor comment relationships
|
||||
Reference in New Issue
Block a user