/Catalogue/Prompt/hoangsonww/hoangsonww-claude-code-agent-monitor-memory-review

Origin: github

memory-review

Review the file-based memory store via the Agent Monitor Config Explorer API: the user and project CLAUDE.md plus per-project auto-memory files under ~/.claude/projects/<slug>/memory/*.md. Groups by project, shows the index (MEMORY.md) vs per-fact files, and flags stale or oversized facts. Reads /api/cc-config/memory and /api/cc-config/file?path=. Use when curating agent memory.

by hoangsonww · updated 21h ago · imported from GitHub

Installs0+0/7d
Security score0/100
Retention 14d0%
GitHub stars1K

Skill logic

Execution graph
User message
Prompt rewrites behaviour
Response

SKILL.md

View on GitHub ↗

Memory Review

Curate the user's file-based agent memory: the long-form CLAUDE.md files plus the per-project auto-memory store — read through the Agent Monitor dashboard at http://localhost:4820.

Input

The user provides: $ARGUMENTS

This may be:

  • empty — review the whole memory store across every project (default).
  • a project slug (e.g. -Users-david-WebstormProjects-foo) — restrict the review to that one project's auto-memory dir.
  • "claude-md" — review only the user/project CLAUDE.md files.

Data Sources

EndpointReturns
GET /api/cc-config/memory{ items:[…] }. CLAUDE.md entries: { scope:"user"|"project", file, size, mtime, preview }. Auto-memory entries: { scope:"auto-memory", project, name, isIndex, file, size, mtime, frontmatter, preview }
GET /api/cc-config/file?path=<abs>full body of one file: { ok, file, size, mtime, truncated, text } — use to read a fact in full before recommending an edit

Report Sections

1. CLAUDE.md overview

List the user and project CLAUDE.md entries with scope, size (KB), and last-modified (mtime). Note any that are truncated (over 256 KB) — these are oversized and worth splitting into auto-memory facts.

2. Per-project auto-memory, grouped

Group scope: "auto-memory" items by project. For each project show the index (isIndex: true, typically MEMORY.md) first, then the per-fact files. For each fact show name, frontmatter.description if present, size, and mtime.

3. Index vs per-fact consistency

Within each project, compare the index (MEMORY.md) against the per-fact files present. Flag facts that exist on disk but are not referenced by the index, and index entries that point at files which no longer appear in /memory.

4. Stale & oversized facts

Flag facts whose mtime is old relative to the rest of the store (stale — candidates to confirm or retire) and facts whose size is large (oversized — candidates to split into smaller, single-fact files). When the user wants to act on one, fetch its full body with GET /api/cc-config/file?path=<file> before recommending changes.

Editing memory (mutations)

Auto-memory files are editable through the Config Explorer. To create/overwrite a fact:

curl -s -X PUT http://localhost:4820/api/cc-config/file \
  -H 'Content-Type: application/json' \
  -d '{"scope":"auto-memory","type":"auto-memory","project":"<slug>","name":"<fact>.md","content":"..."}'

To delete a fact:

curl -s -X DELETE http://localhost:4820/api/cc-config/file \
  -H 'Content-Type: application/json' \
  -d '{"scope":"auto-memory","type":"auto-memory","project":"<slug>","name":"<fact>.md"}'

A timestamped backup is written automatically before any edit or delete. The user/project CLAUDE.md uses type:"memory" with a scope and no name. Never edit or delete a memory file without explicit per-action confirmation from the user — default to read-only review.

Output

  • Section 1 as a short table (Scope | File | Size | Modified | Truncated).
  • Section 2 grouped by project, index first, then facts.
  • Sizes in KB; timestamps as relative age; use ▲ for oversized / stale flags.
  • Cite only fields the API returned — never invent facts, names, or sizes.
  • If the dashboard is unreachable at http://localhost:4820, say so and tell the user to start it with npm start from the repo root.

Discussion

No comments yet — start the thread.

Sign in to join the discussion.

/More from hoangsonww/Claude-Code-Agent-Monitor

hoangsonww· 21h agoSandbox
config-audit

Prompts · TypeScript · v0.1.0

Run a full audit of the user's Claude Code configuration via the Agent Monitor Config Explorer API: counts per surface (user vs project), duplicate or overlapping skills and subagents, hooks that run shell commands, and which surfaces are read-only vs mutable. Reads /api/cc-config/overview, /skills, /agents, /commands, /hooks, and /settings. Use when reviewing your Claude Code setup for sprawl, duplication, or risk.

#ai-agents#claude-agents#claude-code

0 1K
hoangsonww· 21h agoSandbox
hook-inventory

Prompts · TypeScript · v0.1.0

Inventory hooks across the user, project, and project-local settings plus the ~/.claude/hooks scripts directory — read through the Agent Monitor Config Explorer API — and flag hooks that POST to the network or run arbitrary commands. Reads /api/cc-config/hooks and /api/cc-config/hook-scripts. Use when auditing hook safety.

#ai-agents#claude-agents#claude-code

0 1K
hoangsonww· 21h agoSandbox
mcp-audit

Prompts · TypeScript · v0.1.0

Audit the configured MCP servers (user + project scope) via the Agent Monitor Config Explorer API: transport (stdio vs http), command/args and env variable names, headers, and the source file each definition came from. Reads /api/cc-config/mcp. Use when reviewing MCP integrations for hygiene, duplication, or unexpected transports.

#ai-agents#claude-agents#claude-code

0 1K
hoangsonww· 21h agoSandbox
skill-inventory

Prompts · TypeScript · v0.1.0

Inventory the installed skills and which plugins contribute them, then flag overlap with the user's own skills — read through the Agent Monitor Config Explorer API. Reads /api/cc-config/skills and /api/cc-config/plugins. Use when managing skills: deduping, deciding what to keep, or tracing a skill back to the plugin that ships it.

#ai-agents#claude-agents#claude-code

0 1K