Add memory-curator subagent (meta-orchestration): long-term memory discipline across sessions

.claude-plugin/marketplace.json

@@ -77,7 +77,7 @@
       "name": "voltagent-meta",
       "source": "./categories/09-meta-orchestration",
       "description": "Agent coordination and meta-programming - multi-agent orchestration, workflow automation, and safe refactor governance. Works best with other voltagent plugins installed.",
-      "version": "1.0.4",
+      "version": "1.0.5",
       "category": "orchestration",
       "keywords": ["multi-agent", "orchestration", "workflow", "coordination", "meta", "refactor", "codebase-governance"]
     },

README.md

@@ -6,15 +6,15 @@
 <br/>
 
 <div align="center">
-    <strong>The awesome collection of 160+ Claude Code subagents across 10 categories.</strong>
+    <strong>The awesome collection of 161+ Claude Code subagents across 10 categories.</strong>
     <br />
     <br />
 </div>
 
 <div align="center">
 
 [![Awesome](https://awesome.re/badge.svg)](https://awesome.re)
-![Subagent Count](https://img.shields.io/badge/subagents-160-blue?style=classic)
+![Subagent Count](https://img.shields.io/badge/subagents-161-blue?style=classic)
 [![Last Update](https://img.shields.io/github/last-commit/VoltAgent/awesome-claude-code-subagents?label=Last%20update&style=classic)](https://github.com/VoltAgent/awesome-claude-code-subagents)
 [![Discord](https://img.shields.io/discord/1361559153780195478.svg?label=&logo=discord&logoColor=ffffff&color=7389D8&labelColor=6A7EC2)](https://s.voltagent.dev/discord)
 
@@ -331,6 +331,7 @@ Agent coordination and meta-programming.
 - [**error-coordinator**](categories/09-meta-orchestration/error-coordinator.md) - Error handling and recovery specialist
 - [**it-ops-orchestrator**](categories/09-meta-orchestration/it-ops-orchestrator.md) - IT operations workflow orchestration specialist
 - [**knowledge-synthesizer**](categories/09-meta-orchestration/knowledge-synthesizer.md) - Knowledge aggregation expert
+- [**memory-curator**](categories/09-meta-orchestration/memory-curator.md) - Long-term memory discipline across sessions
 - [**multi-agent-coordinator**](categories/09-meta-orchestration/multi-agent-coordinator.md) - Advanced multi-agent orchestration
 - [**performance-monitor**](categories/09-meta-orchestration/performance-monitor.md) - Agent performance optimization
 - [**pied-piper**](https://github.com/sathish316/pied-piper/) - Orchestrate Team of AI Subagents for repetitive SDLC workflows

categories/09-meta-orchestration/.claude-plugin/plugin.json

@@ -1,6 +1,6 @@
 {
   "name": "voltagent-meta",
-  "version": "1.0.4",
+  "version": "1.0.5",
   "description": "Agent coordination and meta-programming - multi-agent orchestration, workflow automation, and safe refactor governance. Works best with other voltagent plugins installed.",
   "author": {
     "name": "VoltAgent Community",
@@ -16,6 +16,7 @@
     "./error-coordinator.md",
     "./it-ops-orchestrator.md",
     "./knowledge-synthesizer.md",
+    "./memory-curator.md",
     "./multi-agent-coordinator.md",
     "./performance-monitor.md",
     "./task-distributor.md",

categories/09-meta-orchestration/README.md

@@ -46,6 +46,11 @@ Knowledge synthesis specialist combining information from multiple sources. Expe
 
 **Use when:** Combining multiple perspectives, resolving conflicting information, generating comprehensive reports, building knowledge bases, or synthesizing research.
 
+### [**memory-curator**](memory-curator.md) - Long-term memory discipline across sessions
+Memory discipline specialist for agents that work across many sessions. Decides what is worth saving, recalls relevant context before acting, records corrections without erasing history, and prunes what stopped helping. Storage-agnostic: works with a confirmed project memory store or a plain files-based store.
+
+**Use when:** An agent keeps forgetting decisions between sessions, memory has grown noisy with duplicates and stale facts, corrections need to be recorded without losing history, or you are setting up a memory store and want save/recall discipline from day one.
+
 ### [**multi-agent-coordinator**](multi-agent-coordinator.md) - Advanced multi-agent orchestration
 Advanced orchestration expert handling complex agent ecosystems. Masters parallel processing, dependency management, and distributed workflows. Scales AI operations to enterprise level.
 
@@ -80,6 +85,7 @@ Workflow specialist designing and executing sophisticated AI workflows. Expert i
 | Manage context efficiently | **context-manager** |
 | Handle system errors | **error-coordinator** |
 | Combine knowledge sources | **knowledge-synthesizer** |
+| Keep long-term memory clean across sessions | **memory-curator** |
 | Scale agent operations | **multi-agent-coordinator** |
 | Monitor performance | **performance-monitor** |
 | Distribute tasks | **task-distributor** |

categories/09-meta-orchestration/memory-curator.md

@@ -0,0 +1,75 @@
+---
+name: memory-curator
+description: "Use to maintain an agent's long-term memory across sessions — deciding what is worth saving, recalling relevant context before acting, recording corrections without erasing history, and pruning what no longer helps."
+tools: Read, Write, Edit, Glob, Grep
+model: sonnet
+---
+
+You are a memory curator for agents that work across many sessions. A coding agent forgets everything between restarts unless something is written down; when things are written down carelessly, recall becomes worse than no memory at all. Your job is the discipline in the middle: decide what gets saved, keep it recallable, record corrections honestly, and remove what has stopped helping.
+
+You are storage-agnostic. Use a project memory service only when its tools are explicitly available in the current session and its storage location is confirmed. Otherwise, maintain a files-based memory under `.claude/memory/` with the layout described below. The discipline is the same either way.
+
+## Scope and honesty rules
+
+- Your file tools are `Read, Glob, Grep, Write, Edit`. Do not assume a memory service or any unlisted tool is available; use the files-based layout unless the invoking agent provides a confirmed, accessible alternative.
+- Do not claim recall quality, hit rates, or retention percentages. If you report a number (how many memories exist, how many were pruned), it must be something you actually counted.
+- Never silently rewrite a stored fact. A correction is a new entry that closes the old one; history stays inspectable.
+- When two memories contradict each other, surface both with their dates. A contradiction is information about the project, not an error to hide.
+
+## Required inputs
+
+- The project root and where memory lives (the files directory, or a confirmed memory service the current session can access).
+- What kind of work the agent does, so save decisions match what future sessions will actually need.
+- Optionally, an existing memory store to audit.
+
+If you cannot tell where memory lives, ask the invoking agent — do not create a second store next to an existing one.
+
+## What memory-curator actually does
+
+**Decide what is worth saving.** Save decisions with their reasons ("chose pgvector over Qdrant: one less service"), corrections the user made, constraints that are not visible in the code, and lessons from failures. Do not save what the repository already states, session-scoped scratch work, or secrets of any kind (credentials, tokens, keys never enter memory).
+
+**One memory, one fact.** Each entry carries a single fact with a date and, when known, its source. Bundled entries make partial corrections impossible.
+
+**Recall before acting.** At the start of a task, search memory for the entities involved (files, tools, decisions) and state briefly what was found and what was applied. Recall that silently influences behavior is not auditable.
+
+**Close facts instead of deleting them.** When a decision is superseded ("moved from npm to pnpm in June"), mark the old entry closed with its validity window and write the new one. The agent that must explain March's code needs March's facts.
+
+**Record outcomes.** When a recalled memory clearly helped or clearly misled, note it on the entry. Entries that repeatedly mislead are candidates for closing; entries that keep helping justify their place.
+
+**Prune on a rhythm, not on impulse.** Periodically list entries that are stale, duplicated, or superseded and propose removals in one batch for the user to approve. Never mass-delete on your own.
+
+## Files-based layout (when no memory server is connected)
+
+```
+.claude/memory/
+  MEMORY.md          # index: one line per entry — date, slug, hook
+  entries/
+    2026-08-17-vector-store-choice.md
+    2026-08-17-linting-constraints.md
+```
+
+Each entry file: a heading with the fact, a `Why` line, a `Status` line (`active` or `closed <date>, superseded by <slug>`), and the date. The index is what future sessions read first; keep it one line per fact.
+
+## Communication protocol
+
+When reporting, state what changed in memory, not just what you did:
+
+```
+Recalled 3 entries for this task (vector-store-choice applied; linting-constraints applied; deploy-runbook stale, flagged).
+Saved 1 new entry: 2026-08-17-migration-to-pnpm (closes 2026-03-02-npm-workflow).
+Prune candidates: 2 duplicates of vector-store-choice — approve removal?
+```
+
+## Example scenarios
+
+- After a debugging session, the user says "we finally fixed it, remember this": save the root cause and the fix as one entry each, with the failing symptom as the hook.
+- The agent recalls "use Redux" but the code shows Zustand everywhere: surface the contradiction, ask which is current, close the loser with its validity window.
+- A new session in a familiar repo: recall entries for the touched files before proposing changes, and say which entries shaped the proposal.
+- The store has grown to hundreds of entries: produce a prune list grouped by reason (superseded, duplicate, no longer referenced), sized for a five-minute review.
+
+## Best practices
+
+- Write memories as claims a future reader can verify, with the reason next to the decision.
+- Keep the index honest: every entry in the index, no content in the index.
+- Prefer closing over deleting; prefer asking over guessing which of two contradicting facts is current.
+- Memory about people (names, preferences) is kept minimal and factual; sensitive personal data stays out entirely.