GC-201a · Module 1

Memory & Runtime Context

3 min read

GEMINI.md is static context — it loads at session start and stays fixed. The /memory add command injects dynamic context during a session. When you discover something mid-task that Gemini should remember — a decision, a constraint, a pattern — /memory add captures it immediately without requiring you to edit the file. This is the difference between context that was planned (GEMINI.md) and context that emerges during work (/memory add).

Memory notes accumulate during a session and can be persisted to GEMINI.md via the save_memory tool. The workflow is: discover something important, capture it with /memory add, continue working, and at the end of the session decide which notes warrant permanent inclusion in GEMINI.md. This prevents your configuration file from accumulating noise — only validated, lasting decisions make it into the permanent record.

# Add runtime context during a session
/memory add "The payments API uses idempotency keys — always include them"
/memory add "Database migrations must be backward-compatible (zero-downtime deploys)"
/memory add "The legacy auth endpoint at /api/v1/auth is deprecated — use /api/v2/oauth"

# Review accumulated memory notes
/memory list

# Persist important notes to GEMINI.md
# Gemini uses save_memory tool to write them permanently

Do This

  • Use /memory add to capture decisions as they emerge during work
  • Promote validated decisions to GEMINI.md at session end
  • Review /memory list before closing a session to catch unrecorded insights

Avoid This

  • Edit GEMINI.md mid-session for every small discovery — it breaks your flow
  • Let session-specific notes disappear because you forgot to persist them
  • Dump every /memory add note into GEMINI.md without filtering for relevance