Power Memory Invoker

The Power Memory Invoker command manages project knowledge and memory across development sessions, ensuring that important context, decisions, and patterns are captured, organized, and retrievable. It reads, updates, and queries project memory files that persist critical information between conversations and team interactions. Execute this command when you need to store architectural decisions, capture session learnings, or retrieve previously documented context for continuity.

When to Use This Command

Run this command when...

• You need to record an important architectural decision, coding convention, or project-specific rule in persistent memory
• You want to retrieve previously documented context about a module, feature, or system behavior before making changes
• You are starting a new development session and need to restore context about ongoing work from previous sessions
• You want to organize scattered project knowledge into structured memory files that the team can reference
• You need to update memory entries that have become stale due to refactoring, migration, or design changes

Consider alternatives when...

• You are documenting code at the function or class level, which inline documentation and JSDoc comments handle more effectively
• You need to create user-facing documentation like README files or API guides rather than internal memory notes
• Your knowledge management needs require a full wiki or knowledge base platform rather than file-based memory

Quick Start

Copy
# memory-config.yml
memory:
  location: ".claude/memory"
  format: "markdown"
  categories:
    - architecture
    - conventions
    - decisions
    - learnings
    - environment
search:
  fuzzy: true
  index-on-update: true
retention:
  auto-archive: true
  archive-after-days: 90

Example invocation:

Copy
/power-memory-invoker --action store --category decisions --key "auth-strategy"

Example output:

Memory Operation Report
========================
Action: Store
Category: Decisions
Key: auth-strategy

Entry stored:
  Title: Authentication Strategy Decision
  Category: Architecture Decisions
  Date: 2026-03-15
  Content: JWT-based auth with refresh token rotation,
           stored in HttpOnly cookies, 15min access token TTL

Related entries found:
  - session-management (conventions)
  - token-refresh-flow (architecture)
  - cookie-security (decisions)

Memory index updated: 47 total entries across 5 categories

Core Concepts

Concept	Purpose	Details
Persistent Memory	Survive session boundaries	Stores knowledge in files that persist between development sessions, providing continuity across conversations
Categorized Knowledge	Organize by purpose	Structures memory entries into categories such as architecture, conventions, decisions, and learnings for targeted retrieval
Contextual Retrieval	Surface relevant knowledge	Queries memory entries based on keywords, categories, and relationships to surface relevant context for current tasks
Memory Lifecycle	Keep knowledge current	Tracks entry freshness and flags stale entries that may need review or archival after significant codebase changes
Cross-Reference Links	Connect related entries	Links related memory entries together so that retrieving one piece of knowledge surfaces connected context automatically

Architecture: Memory Management
==================================

+-------------------+     +---------------------+     +------------------+
| Memory Interface  | --> | Category Router     | --> | Storage Engine   |
| (CRUD operations) |     | (classify entries)  |     | (file system)    |
+-------------------+     +---------------------+     +------------------+
                                                             |
                          +----------------------------------+
                          v
              +---------------------+     +-------------------+
              | Search Index        | --> | Retrieval Engine   |
              | (keyword + fuzzy)   |     | (ranked results)   |
              +---------------------+     +-------------------+

Configuration

Parameter	Type	Default	Description
action	string	required	Memory operation to perform: store, retrieve, update, delete, search, or list
category	string	""	Category for the memory entry: architecture, conventions, decisions, learnings, or environment
key	string	""	Unique identifier for the memory entry within its category
query	string	""	Search query for retrieving relevant memory entries across all categories
format	string	"markdown"	Output format for retrieved entries: markdown for readable text or json for programmatic use

Best Practices

1. Record architectural decisions at the moment they are made. Decisions lose context rapidly once the discussion concludes. Store the decision, its rationale, the alternatives considered, and the deciding factors immediately after consensus is reached so that future developers understand not just what was decided but why.

2. Use consistent categories and keys for retrievability. Establish naming conventions for categories and entry keys that make entries discoverable through predictable paths. A developer looking for authentication decisions should find them under a consistent decisions/auth-* path rather than scattered across miscellaneous entries.

3. Review and update memory entries during refactoring. When you change the architecture or conventions documented in memory, update the corresponding entries immediately. Stale memory entries are worse than no entries because they mislead developers into following outdated patterns.

4. Link related memory entries to build a knowledge graph. When storing a new entry that connects to existing knowledge, add explicit cross-references so that retrieving one entry surfaces related context. This connected structure makes memory retrieval significantly more useful than isolated entries.

5. Archive rather than delete outdated entries. Historical decisions and deprecated patterns provide valuable context for understanding why the current architecture exists. Archive superseded entries with a note about what replaced them rather than deleting them, preserving the evolutionary history of the project.

Common Issues

Memory entries become stale after codebase changes. When the code evolves but memory entries are not updated, developers encounter contradictions between documented decisions and actual implementation. Schedule periodic memory reviews alongside major refactoring efforts to keep entries aligned with the current codebase.

Search returns too many irrelevant results. Broad search queries against a large memory store can return entries that match keywords but lack contextual relevance. Narrow searches by specifying categories, date ranges, or specific keys to reduce noise and surface the most pertinent entries.

Duplicate entries accumulate for the same knowledge. Without checking for existing entries before storing new ones, the same decision or convention may be recorded multiple times with slight variations. Always search for existing entries before creating new ones and update rather than duplicate when the knowledge already exists.