Build-Time Memory

You manage the build-time memory system that captures development learnings and makes future building faster.

Mode Detection

Parse $ARGUMENTS:

• If empty or "show" -> View Mode
• Otherwise -> Record Mode (the argument is the learning description)

View Mode

Step 1: Read Memory File

Read .outbound-builder-plugin-memory.json from $CLAUDE_PROJECT_DIR. If it doesn't exist, tell the user:

No build-time memory yet. Learnings are recorded automatically after scaffolding,
or you can record one manually:

  /outbound-builder-plugin:remember "Drizzle push needs SSL disabled for Neon"

Step 2: Present Summary

Display the memory in this format:

Build-Time Memory: <N> entries (<M> proven patterns)

Proven Patterns (applied at session start):
  1. [category] Title -- Resolution
  2. ...

Recent Learnings:
  - [category] Title (success_count: N)
  - ...

Categories: error-fix (<N>), api-quirk (<N>), schema-pattern (<N>),
            config-gotcha (<N>), build-pattern (<N>), domain-insight (<N>)

Show up to 10 recent learnings (sorted by date descending). Show all proven patterns.

Record Mode

Step 1: Parse the Learning

From $ARGUMENTS, determine:

• category: One of error-fix, api-quirk, schema-pattern, config-gotcha, build-pattern, domain-insight
  • error-fix -- A coding error and what fixed it
  • api-quirk -- Non-obvious API behavior (rate limits, auth, response format)
  • schema-pattern -- Database schema decision or migration insight
  • config-gotcha -- Configuration that's easy to get wrong
  • build-pattern -- Build/deploy/tooling pattern that works well
  • domain-insight -- Domain-specific knowledge about the pipeline's use case
• title: Short description (under 80 chars)
• description: What happened (1-2 sentences)
• resolution: What fixed it or what to do (1-2 sentences)

If the category isn't obvious from the text, make your best judgment. If the description is too vague to extract a useful learning, ask the user to be more specific.

Step 2: Generate Entry ID

The ID is mem- followed by an 8-character slug derived from category + title. This enables deduplication -- the same learning discovered twice gets the same ID.

To generate: take the first 8 alphanumeric characters of a lowercase, hyphenated version of category-title. For example:

• error-fix + "Drizzle push needs SSL disabled" -> mem-errorfix-

Use python3 for deterministic hashing:

import hashlib
slug = hashlib.md5(f"{category}:{title}".lower().encode()).hexdigest()[:8]
entry_id = f"mem-{slug}"

Step 3: Read or Create Memory File

Read .outbound-builder-plugin-memory.json from $CLAUDE_PROJECT_DIR. If it doesn't exist, initialize:

{
  "version": 1,
  "entries": [],
  "proven_patterns": []
}

Step 4: Dedup and Append

Check if an entry with the same id already exists:

• If yes: Increment success_count and update date to now
• If no: Append a new entry:

{
  "id": "<generated-id>",
  "date": "<ISO timestamp>",
  "category": "<category>",
  "title": "<title>",
  "description": "<description>",
  "resolution": "<resolution>",
  "context": {
    "stage": "manual",
    "files": [],
    "tech": [],
    "domain": null
  },
  "success_count": 1,
  "source": "manual"
}

Step 5: Regenerate Proven Patterns

Scan all entries. Any entry with success_count >= 2 becomes a proven pattern. Rebuild the proven_patterns array:

{
  "id": "<entry-id>",
  "category": "<category>",
  "title": "<title>",
  "resolution": "<resolution>"
}

Step 6: Write and Confirm

Write the updated .outbound-builder-plugin-memory.json and confirm:

Recorded: [category] "title"
  -> resolution

(success_count: N, proven: yes/no)

If this entry just became proven (success_count went from 1 to 2), highlight it:

This pattern is now PROVEN and will be injected at session start.

Rules

• Memory file lives at $CLAUDE_PROJECT_DIR/.outbound-builder-plugin-memory.json
• IDs are deterministic hashes of category:title -- same learning always gets the same ID
• Entries with success_count >= 2 are proven patterns
• Proven patterns are injected by the SessionStart hook at every session start
• Never record routine operations (successful npm install, normal git commands)
• Never record information already documented in imp_doc/
• Keep titles under 80 characters
• Keep descriptions and resolutions to 1-2 sentences each
• The memory file should be committed to the repo (it's project knowledge, not secrets)