Cognitive Memory

# Cognitive Memory — Persistent Knowledge System You have access to a persistent memory system through ClawBuddy. Use it to remember important discoveries, patterns, and rules across sessions. ## Connection All memory API calls use this pattern: ```bash curl -sS -X POST "${CLAWBUDDY_API_URL}/functions/v1/ai-tasks" \ -H "x-webhook-secret: ${CLAWBUDDY_WEBHOOK_SECRET}" \ -H "Content-Type: application/json" \ -d '{...}' ``` ## When to Submit a Memory Submit a memory when you discover ANY of these: 1. **API quirks** — an endpoint behaves unexpectedly, requires specific field names, has undocumented limits, or returns surprising formats 2. **User preferences** — the owner corrects you, states a preference, or says "always/never do X" 3. **Environment facts** — file paths, project structure, tool versions, deployment targets, credentials locations (never the credentials themselves) 4. **Patterns that work** — a code pattern, prompt structure, or approach that solved a recurring problem 5. **Patterns that fail** — something that looks right but breaks, so future sessions don't repeat the mistake ## How to Submit After discovering something worth remembering: ```json { "request_type": "memory", "action": "submit", "content": "Clear, specific description of what was learned. Include the EXACT pattern — not vague summaries. Example: 'delete_data API requires BOTH app_id AND data_id in the payload. Without app_id it returns success but silently does nothing.'", "category": "technical | preference | project | process", "agent_name": "YOUR_AGENT_NAME" } ``` ## Categories | Category | Use for | Example | |----------|---------|---------| | technical | API quirks, code patterns, tool behavior | "Supabase list_data caps at 1000 rows" | | preference | User's stated preferences, style choices | "Owner prefers Tailwind over inline styles" | | project | File locations, architecture, dependencies | "Edge functions are in cosmic-flow-51/supabase/functions/" | | process | Workflow rules, deployment steps, review gates | "Never deploy without running typecheck first" | ## Rules 1. **Be specific, not vague.** Bad: "The API has some quirks with deletion" Good: "delete_data requires both app_id and data_id — without app_id it returns {success: true} but does nothing" 2. **One memory per discovery.** Don't bundle 5 learnings into one entry. Submit them separately so each can be approved or rejected independently. 3. **Never store credentials.** Store WHERE credentials are ("API key is in .env as STRIPE_KEY") but NEVER the actual values. 4. **Submit after every build.** At the end of a build session, review what you learned and submit the most valuable discoveries. Aim for 1-3 memories per build. 5. **Submit immediately on user correction.** When the owner says "No, do it this way" — submit that correction as a memory right then, don't wait until the end. 6. **Memories require approval.** Your submission goes to the dashboard where the owner reviews and approves it. Until approved, it is not persistent. This is intentional — the owner controls what their agents remember permanently. ## Reading Memories At the start of every session, your context should include approved memories. If you need to check for specific knowledge mid-session: ```json { "request_type": "memory", "action": "list", "category": "technical", "agent_name": "YOUR_AGENT_NAME" } ``` ## Post-Build Memory Extraction After completing a build, ask yourself: - Did I hit any errors that took more than one attempt to fix? - Did I discover something about the codebase that wasn't documented? - Did the owner correct my approach at any point? - Did I find a pattern that would save time on similar future tasks? For each "yes," submit a memory entry.