/ork:memory

The /ork:memory command is the read side of OrchestKit's knowledge system. It searches past decisions, loads context at session start, syncs to cloud storage, visualizes the knowledge graph, and reports system health. Paired with /ork:remember (the write side), it forms a persistent memory layer that compounds across sessions -- every decision you store makes future sessions smarter. This page covers each subcommand, the memory architecture, and patterns for getting the most value from persistent knowledge.

Why This Skill

AI assistants forget everything between sessions. You explain the same architectural decisions, technology choices, and project constraints every time you start a new conversation. The /ork:memory skill solves this by maintaining a knowledge graph that persists across sessions. When you start a new session, /ork:memory load restores the context that matters.

This is not just convenience. Memory compounds: a pattern you stored from debugging a Safari cookie issue six months ago surfaces automatically when a teammate encounters a similar problem. Failed approaches are marked so you do not waste time re-exploring dead ends. Over time, the knowledge graph becomes a living record of your project's architectural decisions.

Quick Start

/ork:memory search "pagination strategy"
/ork:memory load
/ork:memory sync
/ork:memory history
/ork:memory viz
/ork:memory status

If you invoke /ork:memory without a subcommand, OrchestKit asks which operation you need.

Subcommands

search -- Find Past Decisions

Search the knowledge graph for entities, decisions, and patterns:

/ork:memory search "cursor pagination"
/ork:memory search --category database "connection pooling"
/ork:memory search --global "caching strategy"

The --global flag searches patterns that apply across all your projects.

Entity types you might find:

Search results automatically adjust based on context window usage: full results when you have room, condensed results when context is tight.

load -- Restore Session Context

Load relevant memories at the start of a session:

/ork:memory load               # Load all relevant context
/ork:memory load --project     # Project-specific only
/ork:memory load --global      # Include global best practices

This pulls in recent decisions, active project context, agent-specific memories, and optionally global patterns. It is most valuable at session start, giving Claude immediate context about your project without you having to re-explain anything.

sync -- Sync Memory

Sync local decisions to the knowledge graph:

/ork:memory sync               # Sync pending changes
/ork:memory sync --force       # Force full sync
/ork:memory sync --dry-run     # Preview what would sync

history -- Decision Timeline

View architecture decisions over time:

/ork:memory history                     # Recent decisions
/ork:memory history --category database # Filter by category
/ork:memory history --since 7d          # Last 7 days
/ork:memory history --mermaid           # Output as Mermaid diagram

The Mermaid output is useful for architecture documentation -- paste it into your docs and you have a visual timeline of how your architecture evolved.

viz -- Knowledge Graph Visualization

Render the knowledge graph as a Mermaid diagram:

/ork:memory viz                          # Full graph
/ork:memory viz --entity "PostgreSQL"    # Focus on one entity
/ork:memory viz --depth 2                # Limit relationship depth
/ork:memory viz --type Technology        # Filter by entity type

status -- Health Check

Check memory system health:

/ork:memory status

Memory System Status:
  Graph Memory:  healthy (42 decisions, 0 corrupt)
  Queue Depth:   3 pending
  CC Native:     active (MEMORY.md present)

The Memory Architecture

OrchestKit uses a 3-tier memory architecture:

High-confidence decisions (score 0.7 or above) are automatically written to CC Native memory (Tier 3), ensuring they persist even without OrchestKit installed.

Common Patterns

Pattern 1: Start-of-Session Context Loading

Begin every session by loading relevant context:

/ork:memory load

This gives Claude immediate awareness of your project's technology choices, past decisions, and known patterns.

Pattern 2: Investigation Acceleration

Before debugging or implementing, search for similar past work:

/ork:memory search "rate limiting"

If your team has already solved a rate limiting problem, the search surfaces the approach, what worked, and what failed.

Pattern 3: End-of-Session Persistence

Before ending a session, store key findings:

/ork:remember Key decisions for authentication feature:
  - Chose JWT over session cookies for API auth
  - Using RS256 for token signing
  - Refresh tokens stored in httpOnly cookies

The next session can restore this context instantly with /ork:memory load.

Pattern 4: Architecture Audit

Visualize how your decisions connect:

/ork:memory viz --type Decision

This produces a Mermaid graph showing all architectural decisions and their relationships, useful for onboarding new team members or reviewing your technical direction.

Tips and Tricks

Related Skills

• /ork:commit -- Commit changes (memory is often referenced during commit)
• /ork:implement -- Implementation draws on past decisions
• /ork:verify -- Verification stores scores in memory
• Memory Architecture -- Deep dive into the 3-tier memory system
• Command Skills Reference -- All 23 command skills