claude-recall 0.5.1 → 0.6.0

package/.claude/skills/memory-management/SKILL.md

@@ -2,8 +2,9 @@
 name: "claude-recall-memory-management"
 description: "Automatic memory capture and retrieval for Claude Recall MCP - ensures you never repeat yourself"
 allowed-tools: "mcp__claude-recall__*"
-version: "0.5.0"
+version: "0.6.0"
 priority: "highest"
+search-first: true
 license: "MIT"
 ---
 
@@ -34,14 +35,23 @@ This Skill teaches Claude Code how to use Claude Recall's persistent memory syst
    - Successful implementations to repeat
    - Failed approaches to avoid
 
-## When to Search Memories (BEFORE ANY TASK)
+## Phase 1: Search Memories (REQUIRED FIRST STEP)
 
-**CRITICAL**: Before file operations, decisions, or implementations, ALWAYS search memories:
+**CRITICAL - ALWAYS SEARCH FIRST**: Before file operations, decisions, or implementations, search memories to find existing context:
 
 ```
 mcp__claude-recall__search("[task keywords] devops preferences success failure correction")
 ```
 
+**Search-First Benefits** (from MCP code execution article):
+- ✅ **Context efficiency**: Only load what you need (not all reference files)
+- ✅ **Token savings**: Search results use fewer tokens than loading all patterns
+- ✅ **Progressive disclosure**: Discover tools/patterns on-demand, not upfront
+
+**When to load references:**
+- ✅ If search found relevant memories → **Skip references**, use memories instead
+- ✅ If search found nothing → Load appropriate reference file from `references/`
+
 ### Search Examples:
 
 **Before creating authentication:**
@@ -120,6 +130,36 @@ mcp__claude-recall__store_memory({
 })
 ```
 
+## Privacy & Security: What NOT to Store
+
+**NEVER store sensitive data in memories:**
+
+❌ **Secrets**:
+- API keys, access tokens, passwords
+- Environment variables with `API_KEY`, `SECRET`, `PASSWORD`, `TOKEN`
+- Private keys, certificates, credentials
+
+❌ **Personal Identifiable Information (PII)**:
+- Email addresses (personal or customer)
+- Phone numbers
+- Social Security Numbers, Tax IDs
+- Credit card numbers, payment info
+
+❌ **Sensitive Configuration**:
+- Production database connection strings with passwords
+- OAuth client secrets
+- Webhook secrets, signing keys
+
+✅ **Safe to store**:
+- General architecture patterns ("We use JWT for auth")
+- Tool choices ("We prefer PostgreSQL")
+- Workflow rules ("Always run tests before commit")
+- Non-sensitive configuration ("API base URL: https://api.example.com")
+
+**Why this matters**: Memories are stored locally but could be exported or synced. Following privacy-by-default prevents accidental leaks.
+
+**See** `references/privacy.md` for detailed examples and automatic filtering patterns.
+
 ## Check What's Captured
 
 To see what memories have been automatically captured:
@@ -198,11 +238,17 @@ User doesn't have to repeat preferences! ✓
 1. Use manual storage for that specific item
 2. The pattern may not have matched - broader trigger words help
 
-**For more examples:**
-- Load `references/devops-patterns.md` for DevOps memory examples
-- Load `references/capture-examples.md` for manual storage templates
-- Load `references/troubleshooting.md` for common issues
+**For more examples (ONLY if search didn't help):**
+- **Search first**, then load references only if needed
+- `references/devops/` - Topic-specific DevOps patterns (git, testing, architecture, etc.)
+- `references/capture-examples.md` - Manual storage templates
+- `references/troubleshooting.md` - Common issues
+- `references/privacy.md` - What NOT to store (secrets, PII)
 
 ---
 
-**Remember**: This Skill ensures the learning loop works automatically. Your job is to search memories BEFORE tasks and trust the automatic capture for most cases.
+**Remember**:
+1. **ALWAYS search first** - Most efficient use of context
+2. **Skip references if search succeeded** - Memories are more relevant than examples
+3. **Trust automatic capture** - Handles most patterns
+4. **The learning loop works best when you search before every task**

package/.claude/skills/memory-management/references/devops/README.md

@@ -0,0 +1,166 @@
+# DevOps Patterns - Topic Index
+
+This directory contains **topic-specific** DevOps memory pattern examples. Load only the files you need for your current task.
+
+## Progressive Disclosure: Load Only What You Need
+
+**DON'T load all files** - This defeats the purpose of progressive disclosure!
+
+**DO search memories first:**
+```
+mcp__claude-recall__search("git workflow testing deployment")
+```
+
+**ONLY load specific files if search didn't help:**
+
+## Available Topics
+
+### 1. Project Identity (`project-identity.md`)
+Load when working on:
+- Understanding what the project is
+- Tech stack questions
+- Dependency requirements
+
+**Contains:**
+- Project purpose patterns
+- Tech stack examples
+- Dependency declarations
+
+### 2. Git Workflows (`git-patterns.md`)
+Load when working on:
+- Git branching strategies
+- Commit message conventions
+- PR/review workflows
+
+**Contains:**
+- Branching strategies (GitFlow, trunk-based, etc.)
+- Commit conventions (conventional commits, etc.)
+- PR and review processes
+
+### 3. Testing Strategies (`testing-patterns.md`)
+Load when working on:
+- Test organization
+- Testing frameworks
+- Coverage requirements
+
+**Contains:**
+- TDD, BDD methodologies
+- Test framework choices
+- Coverage rules
+- Test organization
+
+### 4. Architecture (`architecture-patterns.md`)
+Load when working on:
+- System design decisions
+- Design patterns
+- Integration patterns
+
+**Contains:**
+- Architecture styles (microservices, monolith, etc.)
+- Design patterns (repository, factory, etc.)
+- Communication patterns (REST, GraphQL, events)
+- Scalability and resilience patterns
+
+### 5. Workflow & Environment (`workflow-patterns.md`)
+Load when working on:
+- Development environment setup
+- Team workflow rules
+- Code quality standards
+
+**Contains:**
+- Workflow rules (pre-commit hooks, etc.)
+- Dev environment setup
+- Code quality tools
+- Team conventions
+
+### 6. Build & Deploy (`build-deploy-patterns.md`)
+Load when working on:
+- Build processes
+- CI/CD pipelines
+- Deployment strategies
+
+**Contains:**
+- Build tools and processes
+- CI/CD configurations
+- Deployment strategies
+- Infrastructure as code
+
+## Usage Examples
+
+### Example 1: Git Task
+```
+User: "Create a feature branch for the new API"
+
+Step 1: Search memories
+mcp__claude-recall__search("git branch workflow feature")
+
+Step 2a: If search found results → Use memories (SKIP loading git-patterns.md)
+Step 2b: If search found nothing → Load git-patterns.md for examples
+```
+
+### Example 2: Testing Task
+```
+User: "Add tests for the user service"
+
+Step 1: Search memories
+mcp__claude-recall__search("testing tdd location framework")
+
+Step 2a: If search found results → Use memories (SKIP loading testing-patterns.md)
+Step 2b: If search found nothing → Load testing-patterns.md for examples
+```
+
+### Example 3: Deployment Task
+```
+User: "Deploy to staging"
+
+Step 1: Search memories
+mcp__claude-recall__search("deploy staging ci cd workflow")
+
+Step 2a: If search found results → Use memories (SKIP loading build-deploy-patterns.md)
+Step 2b: If search found nothing → Load build-deploy-patterns.md for examples
+```
+
+## Token Efficiency
+
+**Loading all files: ~8,000 tokens**
+**Loading one file: ~1,500 tokens**
+**Search results: ~500 tokens**
+
+**Best practice: Search first, load only if needed!**
+
+## When to Load Multiple Files
+
+Only load multiple files when working on cross-cutting concerns:
+
+```
+Task: "Set up new project from scratch"
+Relevant files:
+- project-identity.md (tech stack)
+- workflow-patterns.md (dev environment)
+- git-patterns.md (git setup)
+- testing-patterns.md (test framework)
+
+BUT: Still search first! Existing memories might cover everything.
+```
+
+## File Selection Guide
+
+| Your Task | Search Query | If No Results → Load |
+|-----------|--------------|---------------------|
+| Create feature branch | `git branch feature workflow` | `git-patterns.md` |
+| Add tests | `testing tdd location framework` | `testing-patterns.md` |
+| Deploy to production | `deploy production ci cd` | `build-deploy-patterns.md` |
+| Design new service | `architecture microservices api` | `architecture-patterns.md` |
+| Set up dev environment | `dev environment docker local` | `workflow-patterns.md` |
+| Understand project | `project purpose tech stack` | `project-identity.md` |
+
+## Remember
+
+1. **Search memories FIRST** - Most efficient
+2. **Load specific file if search failed** - Progressive disclosure
+3. **Don't load all files** - Wastes tokens
+4. **One file at a time** - Unless cross-cutting concern
+
+---
+
+**See parent `SKILL.md` for complete learning loop workflow.**

package/.claude/skills/memory-management/references/devops/architecture-patterns.md

@@ -0,0 +1,253 @@
+# Architecture Patterns
+
+Patterns for capturing system architecture, design patterns, and structural decisions.
+
+## Architecture Style Examples
+
+**Automatically Captured:**
+- "Uses microservices architecture"
+- "Follows event-driven pattern"
+- "We use MVC design pattern"
+- "Built with serverless architecture"
+- "Monolithic architecture with modular design"
+- "Service-oriented architecture (SOA)"
+
+**Stored As:**
+```json
+{
+  "type": "devops",
+  "category": "architecture",
+  "value": "microservices architecture",
+  "confidence": 0.85
+}
+```
+
+## Design Pattern Examples
+
+**Automatically Captured:**
+- "Repository pattern for data access"
+- "Factory pattern for object creation"
+- "Observer pattern for event handling"
+- "Singleton for configuration"
+- "Dependency injection throughout"
+
+**Examples:**
+```
+✅ "Use repository pattern for database access"
+✅ "Dependency injection via constructor"
+✅ "Factory pattern for creating services"
+✅ "Strategy pattern for payment processors"
+```
+
+## Layered Architecture
+
+**Automatically Captured:**
+- "Three-tier architecture (UI, business, data)"
+- "Clean architecture with domain at center"
+- "Hexagonal architecture (ports and adapters)"
+- "Onion architecture pattern"
+
+**Examples:**
+```
+✅ "Controllers → Services → Repositories"
+✅ "Presentation, domain, infrastructure layers"
+✅ "Core business logic isolated from frameworks"
+✅ "Domain entities never depend on infrastructure"
+```
+
+## Communication Patterns
+
+**Automatically Captured:**
+- "Event-driven with message queues"
+- "REST API for client-server communication"
+- "GraphQL for flexible data fetching"
+- "gRPC for service-to-service calls"
+- "WebSockets for real-time updates"
+
+**Examples:**
+```
+✅ "REST API for public endpoints"
+✅ "Internal services use gRPC"
+✅ "Event bus for async communication"
+✅ "WebSocket for live notifications"
+```
+
+## Data Architecture
+
+**Automatically Captured:**
+- "CQRS (Command Query Responsibility Segregation)"
+- "Event sourcing for audit trail"
+- "Database per microservice"
+- "Shared database with separate schemas"
+- "Read replicas for scaling"
+
+**Examples:**
+```
+✅ "Separate read and write models (CQRS)"
+✅ "Event sourcing for orders"
+✅ "Each service owns its database"
+✅ "Redis for caching layer"
+```
+
+## Scalability Patterns
+
+**Automatically Captured:**
+- "Horizontal scaling with load balancer"
+- "Auto-scaling based on CPU usage"
+- "Stateless services for easy scaling"
+- "CDN for static asset delivery"
+- "Database sharding by tenant ID"
+
+**Examples:**
+```
+✅ "Horizontal pod autoscaling in Kubernetes"
+✅ "Stateless API servers"
+✅ "CloudFront for asset delivery"
+✅ "Database sharded by region"
+```
+
+## Resilience Patterns
+
+**Automatically Captured:**
+- "Circuit breaker for external services"
+- "Retry with exponential backoff"
+- "Bulkhead pattern for isolation"
+- "Fallback to cached data"
+- "Health checks for all services"
+
+**Examples:**
+```
+✅ "Circuit breaker on payment gateway calls"
+✅ "Retry failed requests up to 3 times"
+✅ "Graceful degradation when service unavailable"
+✅ "/health endpoint for monitoring"
+```
+
+## Security Architecture
+
+**Automatically Captured:**
+- "Zero-trust security model"
+- "API gateway for authentication"
+- "OAuth2 for authorization"
+- "Encryption at rest and in transit"
+- "Defense in depth strategy"
+
+**Examples:**
+```
+✅ "API gateway handles auth"
+✅ "JWT tokens for authentication"
+✅ "TLS 1.3 for all connections"
+✅ "Principle of least privilege"
+```
+
+## Complex Architecture Example
+
+**User States:**
+```
+"Our microservices architecture:
+- API Gateway (authentication, rate limiting)
+- User Service (PostgreSQL database)
+- Order Service (PostgreSQL + Redis cache)
+- Payment Service (external Stripe integration)
+- Notification Service (sends emails/SMS)
+- Event Bus (RabbitMQ) connects all services
+- Each service is independently deployable
+- Services communicate via events (async) or REST (sync)"
+```
+
+**Store Manually for Complex Systems:**
+```javascript
+mcp__claude-recall__store_memory({
+  content: `Microservices architecture:
+- API Gateway (auth + rate limiting)
+- User Service (PostgreSQL)
+- Order Service (PostgreSQL + Redis)
+- Payment Service (Stripe integration)
+- Notification Service (email/SMS)
+- RabbitMQ event bus
+- Independent deployment
+- Communication: events (async) + REST (sync)`,
+  metadata: {
+    type: "devops",
+    category: "architecture",
+    style: "microservices",
+    services: 5
+  }
+})
+```
+
+## Integration Patterns
+
+**Automatically Captured:**
+- "API-first design"
+- "Webhook callbacks for async operations"
+- "Polling for legacy systems"
+- "Adapter pattern for third-party APIs"
+
+**Examples:**
+```
+✅ "OpenAPI spec drives implementation"
+✅ "Webhooks for payment notifications"
+✅ "Adapter layer for legacy SOAP services"
+✅ "Anti-corruption layer for external APIs"
+```
+
+## Deployment Architecture
+
+**Automatically Captured:**
+- "Blue-green deployments"
+- "Canary releases for gradual rollout"
+- "Rolling updates in Kubernetes"
+- "Immutable infrastructure"
+
+**Examples:**
+```
+✅ "Blue-green deployment for zero downtime"
+✅ "Canary 10% of traffic to new version"
+✅ "Immutable Docker containers"
+✅ "Infrastructure as code with Terraform"
+```
+
+## Confidence Boosters
+
+These keywords increase confidence for architecture patterns:
+
+- **Strong**: "architecture", "pattern", "design"
+- **Specific**: "microservices", "MVC", "CQRS", "event-driven"
+- **Structural**: "layer", "tier", "module", "service"
+- **Principles**: "separation of concerns", "loose coupling"
+
+**Example:**
+- "use microservices" → 70% confidence
+- "microservices architecture" → 85% confidence
+- "follows microservices architecture pattern" → 92% confidence
+- "our system uses microservices with event-driven communication" → 95% confidence
+
+## What Won't Be Captured
+
+❌ "Maybe try microservices" (uncertain)
+❌ "Should we use MVC?" (question)
+❌ "Consider event-driven" (vague)
+❌ "Microservices could work" (possibility)
+
+**Make it explicit:**
+✅ "Microservices architecture"
+✅ "Use MVC pattern"
+✅ "Event-driven design"
+✅ "CQRS for read/write separation"
+
+## Architecture Anti-Patterns to Store
+
+**Automatically Captured:**
+- "Avoid god objects"
+- "Don't couple services tightly"
+- "No circular dependencies"
+- "Avoid shared database across services"
+
+**Examples:**
+```
+✅ "Never create god classes"
+✅ "Services must be loosely coupled"
+✅ "No bidirectional dependencies"
+✅ "Each service owns its data"
+```