Memory Organizer

Organize, compress, and curate OpenClaw memory without polluting permanent memory. Use when the user wants to compress memory files, clean dated memory notes...

Security Scan

The skill's behavior matches its description (organizing and compressing local memory files) but it reads an undeclared environment variable (OPENCLAW_WORKSPACE) and performs destructive file operations in the user's workspace — review and back up your data before use.

Purpose & Capability

Name, README, SKILL.md and the included JS file are coherent: the code implements scanning, compressing, classifying, promoting and discarding markdown memory files in a two-layer model as described. The required capabilities (file read/write in a workspace memory directory) align with the stated purpose.

Instruction Scope

SKILL.md instructs the agent to validate paths, operate only inside the workspace memory files, and preserve backups. The code implements path checks (isPathSafe, isFilenameSafe), creates backups (.bak, .discarded), and limits operations to the workspace memory directory — the runtime instructions and code stay within the declared functional scope.

Install Mechanism

There is no install spec (instruction-only) which is low-risk, but the package includes an executable Node.js script (memory-organizer.js). The README suggests running the script directly (node memory-organizer.js). Because code will be executed on the user's machine, the user should review the script before running it even though there is no remote install/download.

Credentials

The skill reads process.env.OPENCLAW_WORKSPACE to determine workspace location but SKILL.md / registry metadata do not declare required environment variables. This is a mismatch: the script will fall back to ~/.openclaw/workspace-main if the env var is not set, but users should be aware the script uses that env var and will operate on local files. No network credentials are requested, but undeclared env access is a notable inconsistency.

Persistence & Privilege

The skill is not always-enabled and does not request elevated platform privileges. However it performs file modifications (compress, rename to .discarded, write .bak backups) inside the user's workspace. That is expected for this functionality but is a persistent effect on local files; the user should ensure backups and run cautiously.

What to consider before installing

This skill appears to do what it says (organize and compress local memory markdown files), but it will modify your files in-place (creates .bak and .discarded files, overwrites originals when compressing) and reads the OPENCLAW_WORKSPACE environment variable even though no env vars were declared. Before installing or running: 1) review memory-organizer.js (it's included) to confirm there are no network calls or unexpected behavior (there are none obvious, but inspect the whole file). 2) Set OPENCLAW_WORKSPACE to a test or temporary workspace, or verify the default path (~/.openclaw/workspace-main) is the intended target. 3) Make a full backup/copy of your MEMORY.md and memory/ directory. 4) Run operations first in non-forcing mode (-– without force) to see what would change; note discard requires --force to actually delete/move files. 5) If you lack the ability/comfort to audit the code, run it in an isolated environment or container. These steps reduce the risk of accidental data loss even though the skill's functionality is generally coherent with its description.

Memory Organizer Skill

Organize memory with a strict two-layer model.

Core Rule

Treat MEMORY.md as a small permanent index.

Do not copy every dated memory file into MEMORY.md. Do not turn daily logs into permanent memory. Keep historical details inside memory/YYYY-MM-DD.md files unless a fact is clearly long-lived and should be loaded in every new session.

Memory Model

1. Permanent memory: MEMORY.md

Keep only information that is worth reading every session:

• Stable user preferences
• Durable identity or relationship facts
• Long-lived project configuration
• Important workspace rules
• Cross-session todos that are still active
• Reusable operational facts that will matter again

This file should stay short, clean, deduplicated, and easy to scan.

2. Daily memory: memory/YYYY-MM-DD.md

Keep session-specific and historical detail here:

• Daily work logs
• Intermediate reasoning summaries
• One-off experiments
• Temporary debugging notes
• Daily outcomes and progress notes
• Detailed records that are useful later, but not required every session

When compressing or organizing memory, preserve these files instead of moving everything into permanent memory.

Decision Rule: Promote or Keep Local

Before writing anything into MEMORY.md, ask:

1. Will this likely matter across many future sessions?
2. Does it need to be loaded immediately at session start?
3. Is it stable enough that it will not create clutter soon?

Only promote the item when the answer is clearly yes.

If the item is useful mainly as history, context, or audit trail, keep it in the dated file.

What to Promote

Promote only concise bullets such as:

• User prefers short paragraphs and punchy style
• Workspace path or permission boundary that must always be respected
• Current active project rule that affects future execution
• Ongoing todo that spans multiple days

What Not to Promote

Do not promote these by default:

• Full daily summaries
• Per-day changelogs
• Detailed task execution logs
• Debugging transcripts
• Temporary ideas
• Repeated notes already represented in MEMORY.md
• Every published result or status check

Compression Workflow

When the user asks to compress or organize memory:

1. Scan MEMORY.md and dated memory files separately.
2. Clean and deduplicate MEMORY.md first.
3. Compress dated files in place.
4. Preserve useful historical notes inside their original memory/YYYY-MM-DD.md files.
5. Promote only a very small set of durable facts into MEMORY.md.
6. If unsure whether something is permanent, leave it in the dated file.

Merge Workflow

If using a merge or promotion action:

• Merge selectively, not wholesale.
• Extract only durable bullets.
• Skip daily summaries, logs, and verbose headings.
• Avoid adding duplicate sections for each date.
• Prefer updating an existing permanent section over appending a new date-based block.

Quality Bar

MEMORY.md should remain:

• Short enough for routine startup loading
• Structured by durable topic, not by date
• Free from noisy history
• Focused on must-know information

If a choice would make MEMORY.md longer but not more reusable, keep that content in the dated memory file instead.

Safety

• Validate paths before file operations.
• Operate only inside the workspace memory files.
• Prefer backup before destructive compression.
• When deleting or discarding memory, preserve recoverable backups when possible.