How does short term memory.md get converted to long term memory files? | Friends of the Crustacean 🦞🤝 | Page 1

fallow geode Apr 21, 2026, 2:55 PM

#

I have noticed that I need to give explecit instructions to agents that they need to save to memory.md files and that they need to turn that memory into longterm files. I would have thought that OpenClaw would have these skills automatically build in. And that we do not need to invent the wheel over and over again. Also when an agent does have a memory.md file and I ask it to search its memory it also searches the dreaming session output files on disk.

How can I make sure my agents use memory files as good as possible? and how can I prevent them from reading the dreaming session files that only add noise?

regal thornBOT Apr 21, 2026, 2:55 PM

#

coarse canyonBOT Apr 21, 2026, 2:55 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

fallow geode Apr 21, 2026, 2:58 PM

#

@peak wave any suggestions?

peak waveBOT Apr 21, 2026, 3:01 PM

#

fallow geode <@1457407575476801641> any suggestions?

Let me check the docs/code path for this so I don’t make up config keys.

#

First, what does openclaw --version show?

You’re not wrong, some of this is built in now, but not all of it.

What OpenClaw already does:

memory flush before compaction is automatic
memory_search defaults to memory files, not session transcripts
Dreaming can promote short-term notes into MEMORY.md, but it is opt-in

What is not automatic enough by default:

creating/curating MEMORY.md
teaching every agent your preferred memory workflow
preventing a model from doing a dumb raw filesystem search unless you tell it not to

Best practice

Put a small policy in AGENTS.md:

#

## Memory policy
- Use `memory_search` and `memory_get` for recall.
- Do not use raw filesystem search for “search memory” unless explicitly asked.
- Save short-term notes in `memory/YYYY-MM-DD.md`.
- Save durable facts, preferences, and decisions in `MEMORY.md`.
- Ignore `memory/.dreams/`, `DREAMS.md`, and session transcript files unless the user explicitly asks about dreaming or transcript history.

If you want automatic short-term → long-term promotion

Enable Dreaming:

{
  plugins: {
    entries: {

#

      "memory-core": {
        config: {
          dreaming: {
            enabled: true
          }
        }
      }
    }
  }
}

Or do it manually with:

openclaw memory promote --apply

#

To stop transcript/dreaming noise

Make sure session memory is off, or at least memory-only:

{
  agents: {
    defaults: {
      memorySearch: {
        experimental: { sessionMemory: false },
        sources: ["memory"]
      }
    }
  }
}

If you use QMD instead of builtin memory:

#

{
  memory: {
    backend: "qmd",
    qmd: {
      sessions: { enabled: false }
    }
  }
}

Also check that you did not add session/artifact folders under memorySearch.extraPaths.

One important Discord nuance

In guild channels, MEMORY.md is not auto-loaded. So for channel use, either:

keep the rule in AGENTS.md / USER.md, or
explicitly tell the agent to use memory_search / memory_get

#

Docs:

If you paste:

openclaw --version
openclaw memory status --deep

I can help pinpoint whether this is config, raw-file-search behavior, or an older-version bug.

fallow geode Apr 21, 2026, 3:08 PM

#

OpenClaw 2026.4.15 (041266a)

◒ Probing embeddings…[node-llama-cpp] The prebuilt binary for platform "linux" "x64" with Vulkan support is not compatible with the current system, falling back to using no GPU
◒ Probing embeddings….(node:2262801) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 beforeExit listeners added to [process]. MaxListeners is 10. Use emitter.setMaxListeners() to increase limit
(Use node --trace-warnings ... to show where the warning was created)
Memory Search (orion)
Provider: local (requested: local)
Model: /home/najef/.cache/qmd/models/hf_ggml-org_embeddinggemma-300M-Q8_0.gguf
Sources: memory
Indexed: 10/13 files · 66 chunks
Dirty: no
Store: ~/.openclaw/memory/orion.sqlite
Workspace: ~/.openclaw/agents/orion
Dreaming: 0 3 * * * · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
Embeddings: ready
By source:
memory · 10/13 files · 66 chunks
Vector: ready
Vector dims: 768
Vector path: ~/.nvm/versions/node/v24.14.1/lib/node_modules/openclaw/node_modules/sqlite-vec-linux-x64/vec0.so
FTS: ready
Embedding cache: enabled (189 entries)
Batch: disabled (failures 0/2)
Recall store: 457 entries · 3 promoted · 457 concept-tagged · 287 spaced · scripts=457 latin
Recall path: ~/.openclaw/agents/orion/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-21T01:11:01.623Z
Dreaming artifacts: diary present · 4 corpus files · ingestion state present
Dream corpus: ~/.openclaw/agents/orion/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/agents/orion/memory/.dreams/session-ingestion.json
Dream diary: ~/.openclaw/agents/orion/DREAMS.md

peak waveBOT Apr 21, 2026, 3:08 PM

#

That status is actually pretty revealing.

What it says

Sources: memory means session transcript search is off
Dreaming is already enabled
3 promoted means short-term → MEMORY.md is already happening
the Dreaming artifacts: lines are just status/reporting, not proof those files are in the memory index

So the likely problem is not memory_search itself.

It’s much more likely the agent is doing a generic file/search tool sweep when you say “search your memory”, and that catches memory/.dreams/*, DREAMS.md, or other noise on disk.

Best fix

Put the rule in the agent’s AGENTS.md, not in MEMORY.md:

#

## Memory rules
- When asked to "search memory", use `memory_search` or `memory_get`.
- Do not use raw filesystem search/read tools for memory lookup unless explicitly asked.
- Ignore `memory/.dreams/`, `DREAMS.md`, and any session transcript/artifact files unless the user explicitly asks about dreaming or transcript history.
- Save short-term context in `memory/YYYY-MM-DD.md`.
- Save durable facts, preferences, and decisions in `MEMORY.md`.

Why this matters

AGENTS.md is the right place for behavior policy
MEMORY.md is for facts/preferences/decisions
if you want this to apply across sessions and subagents, AGENTS.md is the safer place

About long-term promotion

For Orion, it’s already on. Your status shows:

Dreaming enabled

#

recall store active
3 promoted

So you do not need to invent the whole promotion pipeline yourself here.

If you want to force a review/apply pass manually:

openclaw memory promote
openclaw memory promote --apply

Quick sanity check

Run this once:

openclaw memory search "some query" --json

#

Then inspect the returned path values.

If you see only MEMORY.md / memory/..., memory search is fine, and the issue is agent tool choice.
If you see sessions/..., memory/.dreams/..., or dream/session artifacts in results, that’s a real bug.

Also, the Vulkan fallback + MaxListenersExceededWarning are unrelated to this memory behavior.

Docs:

If you want, I can help you write a tight AGENTS.md memory policy for Orion that keeps recall clean without making the agent too rigid.

fallow geode Apr 21, 2026, 3:15 PM

#

what prompt could I add to the heartbeat.md that would help with memory hygiene?

peak waveBOT Apr 21, 2026, 3:16 PM

#

Yes. I’d keep it short and strict.

A good HEARTBEAT.md for memory hygiene would be:

If there is no higher-priority task, do a small memory hygiene pass.

Rules:
- Use `memory_search` or `memory_get` for memory recall, not raw filesystem search.
- Do not read `memory/.dreams/`, `DREAMS.md`, or session transcript/artifact files unless explicitly asked.
- Review only recent memory notes when needed.
- Promote only durable facts, preferences, decisions, and recurring lessons into `MEMORY.md`.
- Keep transient chatter, one-off logs, and dream/session noise out of `MEMORY.md`.
- Deduplicate or tighten existing `MEMORY.md` entries when helpful.
- Make at most one small memory update per heartbeat unless urgent.
- If no worthwhile memory cleanup is needed, reply HEARTBEAT_OK.

#

If you want an even tighter version:

Memory hygiene only:
- Recall with `memory_search` / `memory_get`, never raw file search.
- Ignore `memory/.dreams/`, `DREAMS.md`, and session artifacts.
- Keep `MEMORY.md` durable and compact.
- Promote only genuinely reusable facts.
- If nothing needs cleanup, reply HEARTBEAT_OK.

My recommendation is the first one, because it gives enough guidance without making heartbeats ramble or over-edit memory.

fallow geode Apr 21, 2026, 3:18 PM

#

should the recall also be in heartbeat.md? I though something more like read your memory.md file make sure that there are no dublicates, projects and data that you know are not directly relevant anymore move to the long term memory files, then scan long term memory files and make sure there are no contradictions...

peak waveBOT Apr 21, 2026, 3:19 PM

#

Yes, that idea is better, with one tweak:

I would not make “recall” the main job of the heartbeat.
I’d make the heartbeat about memory maintenance, and say recall should use memory_search / memory_get if needed.

Also, use MEMORY.md for long-term, not lowercase memory.md unless you’re relying on the legacy fallback.

Recommended shape

every heartbeat: small hygiene pass
occasionally: deeper contradiction/cleanup pass
never: scan memory/.dreams/, DREAMS.md, or session artifacts unless explicitly asked

Good `HEARTBEAT.md`

If there is no higher-priority task, do one small memory maintenance pass.

#

Memory maintenance rules:
- Use `memory_search` / `memory_get` if recall is needed.
- Review `MEMORY.md` and the most relevant recent memory notes.
- Remove duplicates from `MEMORY.md`.
- Promote durable facts, preferences, decisions, and recurring lessons into `MEMORY.md`.
- Move stale but still useful project detail out of `MEMORY.md` into more specific memory files when helpful.
- Look for contradictions in long-term memory and reconcile them conservatively.
- Ignore `memory/.dreams/`, `DREAMS.md`, and session/artifact files unless explicitly asked.
- Keep edits small and high-signal.
- If no worthwhile cleanup is needed, reply HEARTBEAT_OK.

One caution

I would not tell it to scan all long-term memory files every heartbeat. That can get noisy and expensive.

Better wording is:

#

review MEMORY.md
review the most relevant recent notes
do small cleanup only

If you want, I can also give you a stronger weekly-cleanup version and a lighter daily version.

fallow geode Apr 21, 2026, 3:21 PM

#

give me stronger weekly-cleanup version and a lighter daily version.

peak waveBOT Apr 21, 2026, 3:22 PM

#

Yep, here are both.

Lighter daily version

If there is no higher-priority task, do a small daily memory hygiene pass.

Daily memory rules:
- Use `memory_search` / `memory_get` if recall is needed.
- Review `MEMORY.md` and only the most relevant recent memory notes.
- Promote only clearly durable facts, preferences, decisions, and recurring lessons.
- Remove obvious duplicates from `MEMORY.md`.
- Keep edits small and high-signal.
- Ignore `memory/.dreams/`, `DREAMS.md`, and session/artifact files unless explicitly asked.
- If no worthwhile cleanup is needed, reply HEARTBEAT_OK.

Stronger weekly-cleanup version

#

If there is no higher-priority task, do a weekly memory consolidation pass.

Weekly memory rules:
- Use `memory_search` / `memory_get` if recall is needed.
- Review `MEMORY.md` carefully.
- Review recent memory notes and any clearly relevant long-term memory files.
- Promote durable facts, preferences, decisions, project state, and recurring lessons into long-term memory.
- Remove duplicates, stale items, and low-value clutter from `MEMORY.md`.
- Move detailed but still useful project material out of `MEMORY.md` into more specific long-term memory files when helpful.
- Look for contradictions in long-term memory and reconcile them conservatively.
- Prefer concise, canonical entries over repeated variations of the same fact.
- Ignore `memory/.dreams/`, `DREAMS.md`, and session/artifact files unless explicitly asked.
- Keep the memory system tidy, compact, and trustworthy.
- If no worthwhile cleanup is needed, reply HEARTBEAT_OK.

#

My recommendation

use the daily one for normal heartbeats
use the weekly one only on a slower cadence, otherwise the agent may over-edit memory

If you want, I can also give you a combined version with daily + weekly sections in one HEARTBEAT.md.

fallow geode Apr 21, 2026, 3:24 PM

#

please give me the combined version with daily + weekly sections

peak waveBOT Apr 21, 2026, 3:24 PM

#

Absolutely. Here’s a combined version you can paste into HEARTBEAT.md:

If there is no higher-priority task, do memory hygiene.

General rules:
- Use `memory_search` / `memory_get` if recall is needed.
- Do not use raw filesystem search for “search memory” unless explicitly asked.
- Ignore `memory/.dreams/`, `DREAMS.md`, and session/artifact files unless explicitly asked.
- Keep edits small, high-signal, and conservative.
- If no worthwhile cleanup is needed, reply HEARTBEAT_OK.

## Daily memory hygiene
Do this on normal heartbeat runs:
- Review `MEMORY.md` and only the most relevant recent memory notes.
- Promote only clearly durable facts, preferences, decisions, and recurring lessons.

#

- Remove obvious duplicates from `MEMORY.md`.
- Avoid cluttering `MEMORY.md` with transient chatter, one-off logs, or stale detail.

## Weekly memory consolidation
Do this only on a weekly cadence, not every heartbeat:
- Review `MEMORY.md` carefully.
- Review recent memory notes and any clearly relevant long-term memory files.
- Remove duplicates, stale items, and low-value clutter from `MEMORY.md`.
- Move detailed but still useful project material out of `MEMORY.md` into more specific long-term memory files when helpful.
- Look for contradictions in long-term memory and reconcile them conservatively.
- Prefer concise, canonical entries over repeated variations of the same fact.
- Keep the memory system tidy, compact, and trustworthy.

If you want, I can also make this a bit more opinionated for project agents, for example explicitly saying “archive old project state into topical files under memory/ instead of bloating MEMORY.md.”

fallow geode Apr 21, 2026, 3:26 PM

#

instead of asking for improvements step by step, can you give me the best, most optimal and efficieant hearbeat prompt for memory optimazation how we already are discussing?

peak waveBOT Apr 21, 2026, 3:26 PM

#

Yep. If you want one final, efficient, high-signal HEARTBEAT.md prompt for memory optimization, I’d use this:

If there is no higher-priority task, do memory optimization.

Goal:
Keep the memory system compact, accurate, high-signal, and trustworthy over time.

Core rules:
- Use `memory_search` / `memory_get` if recall is needed.
- Do not use raw filesystem search for “search memory” unless explicitly asked.
- Treat `MEMORY.md` as the canonical long-term memory file.
- Keep `MEMORY.md` concise. Prefer updating existing entries over appending near-duplicates.
- Ignore `memory/.dreams/`, `DREAMS.md`, and session/artifact files unless explicitly asked.
- Never promote transient chatter, one-off logs, dream output, or low-value noise into long-term memory.
- If no worthwhile memory work is needed, reply HEARTBEAT_OK.

#


Daily memory hygiene:
- Review `MEMORY.md`.
- Review only the smallest relevant set of recent memory notes.
- Promote clearly durable facts, preferences, decisions, recurring lessons, and active project state into long-term memory.
- Remove obvious duplicates and stale fragments from `MEMORY.md`.
- Tighten wording so long-term memory stays canonical and easy to trust.
- Keep edits small and conservative.

Weekly consolidation:
- Do a deeper review of `MEMORY.md` and clearly relevant long-term memory files.
- Reconcile contradictions conservatively.
- Merge overlapping entries into stronger canonical summaries.
- Move detailed but still useful project material out of `MEMORY.md` into more specific long-term memory files when helpful.
- Remove stale, resolved, or low-value items that no longer deserve top-level long-term memory.

#

- Keep the long-term memory structure tidy, navigable, and low-noise.

Priority order:
1. Accuracy
2. Non-duplication
3. Relevance
4. Concision

When editing memory:
- Prefer modifying an existing entry over creating a new competing one.
- Prefer short durable summaries over verbose notes.
- Preserve genuinely important context, but archive or relocate detail instead of bloating `MEMORY.md`.

That’s the version I’d actually recommend using.

#

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution. This helps Answer Overflow index the solution for future users.

fallow geode Apr 21, 2026, 3:38 PM

#

should I set the options below:

indexDreamReports: false
readMemoryArtifacts: false
and keep indexDailyNotes: true?

peak waveBOT Apr 21, 2026, 3:39 PM

#

fallow geode should I set the options below: indexDreamReports: false readMemoryArtifacts: ...

Let me verify those exact keys before I tell you yes/no.

#

Only if you’re using memory-wiki bridge. Those are memory-wiki bridge settings, not core memory_search settings.

If you are using memory-wiki, my recommendation is:

bridge: {
  enabled: true,
  readMemoryArtifacts: true,
  indexDreamReports: false,
  indexDailyNotes: true,
  indexMemoryRoot: true,
  followMemoryEvents: false // optional, less noise
}

So, direct answers

indexDreamReports: false → yes

#

readMemoryArtifacts: false → no
indexDailyNotes: true → yes

Why

readMemoryArtifacts: false disables the bridge import of memory artifacts entirely, so the other indexing toggles mostly become pointless.
indexDreamReports: false is the correct “don’t pull dream noise in” switch.
indexDailyNotes: true keeps useful short-term/project context available.
indexMemoryRoot: true keeps MEMORY.md in the bridge too, which you almost certainly want.

For your current Orion setup, if you are not using memory-wiki, these settings will not fix the core issue. In that case, the real fix is still:

teach the agent in AGENTS.md to use memory_search / memory_get
tell it to ignore memory/.dreams/, DREAMS.md, and session artifacts
avoid raw filesystem search for “search memory”

Docs: https://docs.openclaw.ai/plugins/memory-wiki

#

Glad we caught that, because readMemoryArtifacts: false sounds right at first, but it would actually turn off the whole bridge import path.

fallow geode Apr 21, 2026, 3:43 PM

#

I am thinking of a crontab that checks OpenClaw systemwide, checks docs.openclaw.ai compares the openclaw config to latest availble and makes improvements. It also scans memory files this would me a monthy or every 2 months crontab

#

also checks openclaw logfiles

peak waveBOT Apr 21, 2026, 3:44 PM

#

fallow geode I am thinking of a crontab that checks OpenClaw systemwide, checks docs.openclaw...

I’d be pretty cautious with that. Let me sanity-check the safest built-in path first.

#

I like the idea, but I would not make it “read docs.openclaw.ai and auto-improve config.”

That part is too brittle.

What I’d recommend instead

Best option, split it into 2 jobs

1. Monthly system audit cron, recommended
Read-only or near-read-only, produces a report.

Use built-in sources of truth:

openclaw status --all
openclaw health --verbose
openclaw update --dry-run
openclaw models status

#

Only use openclaw doctor --non-interactive if you are okay with safe automatic migrations.
If you want pure audit mode, leave doctor for a manual run.

2. Separate memory consolidation cron or heartbeat

review MEMORY.md
review relevant recent memory notes
dedupe
reconcile contradictions
ignore memory/.dreams/, DREAMS.md, and session artifacts

Why split them

System config maintenance and memory cleanup have very different risk levels.

config drift checks should mostly report
memory hygiene can safely edit memory files
docs scraping should not be the mechanism that rewrites your config

#

My recommendation

For your use case:

cron for monthly / every-2-months system audit
heartbeat for light ongoing memory hygiene
optional monthly memory cron for deeper consolidation

If you want one combined cron prompt

Use something like this:

Run a periodic OpenClaw audit and memory consolidation pass.

System audit:
- Check overall health and drift using built-in OpenClaw commands and local state.
- Look for update availability, deprecated config patterns, health issues, auth issues, and obvious maintenance recommendations.

#

- Prefer built-in OpenClaw diagnostics over scraping docs text.
- Do not automatically rewrite gateway config, upgrade OpenClaw, or apply risky system changes without explicit approval.
- Produce a concise report of findings and recommended next actions.

Memory consolidation:
- Review `MEMORY.md` and the smallest relevant set of recent memory notes.
- Promote durable facts, preferences, decisions, recurring lessons, and active project state into long-term memory.
- Remove duplicates, stale fragments, and low-value clutter from `MEMORY.md`.
- Reconcile contradictions conservatively.
- Move detailed but still useful project information out of `MEMORY.md` into more specific long-term memory files when helpful.
- Ignore `memory/.dreams/`, `DREAMS.md`, and session/artifact files unless explicitly asked.

General rules:
- Keep edits conservative and high-signal.
- Prefer reporting over auto-changing system config.

#

- If nothing important needs action, return a short “all clear” summary.

So, short version: yes to the cron idea, no to docs-driven auto-mutation. Use OpenClaw’s own status, health, update --dry-run, and optionally doctor as the maintenance backbone.

Docs:

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution. This helps Answer Overflow index the solution for future users.

#

Yep, that’s a good addition.

I’d add it, but bounded:

check recent OpenClaw logs
look for new or repeated errors, not full-history archaeology
use status/health first, then logs for deeper diagnosis

Good log-review section

Add this to the system audit part:

Log review:
- Check recent OpenClaw logs for repeated errors, restart loops, auth failures, model/provider failures, plugin load issues, cron failures, and stuck-session warnings.
- Focus on recent or recurring problems, not old resolved noise.
- Prefer the latest log tail and high-signal errors over scanning huge historical logs.

#

- If logs show a likely issue, include a short diagnosis and recommended next action in the audit summary.

Best practice

For the monthly cron, I’d make the order:

openclaw status --all
openclaw health --verbose
openclaw update --dry-run
recent log review
memory consolidation

That keeps it efficient, because status --all already gives you a useful log tail before you go digging deeper.

So yes, log review belongs in the cron, just keep it recent and high-signal.

fallow geode Apr 21, 2026, 3:48 PM

#

I was more thinking of a config audit, are all settings we have still the best for our environment, did openclaw release features that we are not using... this kind of need check

peak waveBOT Apr 21, 2026, 3:49 PM

#

Ah, yes, that makes sense, and I think that’s a good cron use case.

A config audit is much better than “auto-improve from docs”.

The key trick

“Best for our environment” is not something docs alone can answer.

The audit needs 3 inputs:

current installed OpenClaw version + current config
current docs / built-in diagnostics
your local intent, meaning what matters in your setup
(cheap models, local-first, Telegram-first, reliability over novelty, strict memory hygiene, etc.)

Without that third part, the agent will keep suggesting churn.

Best pattern

#

Have the cron do a report-only config audit:

what settings still look good
what settings look stale or deprecated
what new features might actually help this environment
what changes are recommended, with rationale and risk
do not auto-apply

This is the kind of prompt I’d use

Run a periodic OpenClaw configuration audit.

Goal:
Determine whether the current OpenClaw setup is still the best fit for this environment, and identify useful new features, migrations, or recommendations that are worth considering.

#

Audit inputs:
- current installed OpenClaw version
- current local OpenClaw config
- current OpenClaw diagnostics and health output
- current OpenClaw docs and documented best practices
- local environment goals and constraints

Audit tasks:
- check whether current settings still make sense for this environment
- identify deprecated, legacy, risky, or obviously stale config patterns
- identify new OpenClaw features or recommended defaults that may now be relevant
- look for opportunities to improve reliability, safety, maintainability, memory hygiene, or cost efficiency
- distinguish between “must fix”, “worth considering”, and “probably keep as-is”

Output format:

#

1. What still looks good
2. What looks outdated or suboptimal
3. New features/config patterns worth considering
4. Recommended changes, with reason and risk
5. Suggested next actions in priority order

Rules:
- prefer OpenClaw built-in diagnostics and documented behavior over guesswork
- do not auto-apply config changes
- do not rewrite config just because something newer exists
- optimize for fit to this environment, not novelty
- keep the report concise and actionable

One more improvement

If you want this to be really good, create a tiny local “intent” note, something like:

#

## Environment goals
- prefer stability over bleeding-edge features
- prefer lower-cost models for routine automation
- keep memory high-signal and compact
- avoid noisy dreaming/session artifacts in recall
- only adopt new features when they clearly improve reliability, cost, or usability

That gives the cron a real baseline for deciding what “best” means.

So yes, monthly or every 2 months for this kind of audit sounds pretty reasonable.

fallow geode Apr 21, 2026, 3:50 PM

#

what about automatically implementing or correcting small quick win improvements?

peak waveBOT Apr 21, 2026, 3:51 PM

#

Yes, but keep that lane very narrow.

I’d allow automatic quick wins only when they are:

low-risk
reversible
local-only
documented
not auth-related
not network-exposure-related
not model/cost-changing
not likely to require human judgment

Good candidates for auto-fix

These are usually fine:

safe config normalization / legacy-key cleanup

#

removing duplicate or obviously dead config entries
small memory dedupe / contradiction cleanup
tightening MEMORY.md wording without changing meaning
documented migration-style fixes that OpenClaw already treats as safe

Bad candidates for auto-fix

These should stay report-only:

changing models/providers
changing auth or tokens
changing tool permissions
changing gateway exposure / network / browser attach settings
enabling new features just because they exist
anything that changes cost, reach, or trust boundaries
anything requiring a restart unless you explicitly allowed that

Best policy

#

I’d add a “quick wins” rule like this:

Quick wins policy:
- You may automatically apply only low-risk, reversible, local-only improvements.
- Allowed: safe config normalization, deprecated-key cleanup, duplicate removal, tiny memory hygiene fixes, and clearly documented migration-style improvements.
- Not allowed: upgrades, model/provider changes, auth changes, permission changes, network-exposure changes, or anything with meaningful behavior/cost/risk impact.
- If a change is not obviously safe, report it instead of applying it.
- After any automatic quick win, include a short change summary explaining exactly what was changed and why.

My recommendation

Use this split:

auto-apply only tiny hygiene fixes
report everything else
let openclaw doctor handle the official safe migration lane

#

let your cron focus on identifying opportunities, not being too clever

That’s the sweet spot, useful without becoming scary.

fallow geode Apr 21, 2026, 3:54 PM

#

can you suggest a detailed and complete prompt? something also describing how to format the report?

peak waveBOT Apr 21, 2026, 3:55 PM

#

Yep. Here’s a detailed, complete prompt I’d actually use for a monthly or every-2-months OpenClaw audit cron.

Run a periodic OpenClaw system, configuration, logs, and memory audit.

## Mission
Evaluate whether the current OpenClaw setup is still a good fit for this environment, identify useful new capabilities or best-practice changes worth considering, apply only clearly safe quick wins, and produce a concise but complete audit report.

## Primary goals
1. Check overall OpenClaw health.
2. Audit current config for drift, stale choices, deprecated patterns, and missed opportunities.
3. Check whether newer OpenClaw features or recommended patterns may now be relevant.
4. Review recent logs for repeated or actionable issues.
5. Perform conservative memory hygiene.
6. Apply only very low-risk quick wins.
7. Produce a clear report with findings, changes, and recommendations.

#


## Optimization priorities
Prioritize in this order:
1. Reliability
2. Safety
3. Maintainability
4. Memory quality
5. Cost efficiency
6. Feature adoption

Do not optimize for novelty alone.

## Inputs to consider
Use the following as your sources of truth:
- current installed OpenClaw version

#

- current OpenClaw config
- OpenClaw built-in diagnostics and health/status output
- current OpenClaw docs and documented best practices
- recent OpenClaw logs
- current memory files
- local environment goals and constraints, if documented anywhere in the workspace

If local goals or constraints are available, use them as the baseline for deciding what “best for this environment” means.

## General rules
- Prefer OpenClaw built-in diagnostics and documented behavior over guesswork.
- Do not blindly rewrite config just because something newer exists.
- Distinguish between:
  - must fix
  - worth considering

#

  - keep as-is
- Be conservative with changes.
- If a change is not obviously safe, report it instead of applying it.
- Keep the report high-signal and actionable.

## Configuration audit scope
Audit the setup for:
- deprecated or legacy config patterns
- stale or redundant settings
- settings that are no longer a good fit for the environment
- settings that are missing but would materially improve reliability, safety, memory hygiene, or cost efficiency
- newly relevant OpenClaw features that may now be worth considering
- health or maintenance issues that should be fixed soon

When evaluating config, ask:

#

- Is this setting still appropriate for this environment?
- Is it still aligned with documented current best practices?
- Is there a safer, simpler, or more maintainable equivalent?
- Is a new feature available that is genuinely useful here?
- Would changing this introduce risk, churn, or cost without enough value?

## Log review scope
Review recent OpenClaw logs and look for:
- repeated errors
- restart loops
- auth failures
- model/provider failures
- plugin load issues
- cron failures
- session issues

#

- warnings that are recurring or likely actionable

Focus on recent or repeated problems, not old resolved noise.

## Memory hygiene scope
Perform conservative memory optimization:
- Use `memory_search` / `memory_get` if recall is needed.
- Do not use raw filesystem search for “search memory” unless explicitly needed.
- Review `MEMORY.md` and only the smallest relevant set of recent memory notes.
- Promote durable facts, preferences, decisions, recurring lessons, and active project state into long-term memory.
- Remove obvious duplicates and stale fragments from `MEMORY.md`.
- Reconcile contradictions conservatively.
- Prefer concise, canonical long-term entries over repeated variants.
- Ignore `memory/.dreams/`, `DREAMS.md`, and session/artifact files unless explicitly asked or clearly relevant to diagnosing a real issue.
- Do not promote dream/session noise into long-term memory.

#


## Quick wins policy
You may automatically apply only low-risk, reversible, local-only improvements.

Allowed automatic quick wins:
- safe config normalization
- deprecated-key cleanup
- removing clearly duplicate or dead config entries
- tiny memory hygiene fixes
- clearly documented migration-style improvements with very low risk

Do NOT automatically apply:
- upgrades
- model/provider changes
- auth changes

#

- token changes
- permission changes
- network exposure changes
- browser attach/security changes
- feature enablement with meaningful behavior or cost impact
- anything that needs real human judgment
- anything with unclear blast radius

If unsure, report it instead of changing it.

## Desired workflow
Follow this order:

1. Capture environment snapshot
   - installed OpenClaw version

#

   - key environment details that matter for the audit

2. Run health and maintenance checks
   - inspect OpenClaw health/status
   - check update availability
   - check whether config appears current or stale
   - check whether logs show recurring issues

3. Audit current config
   - identify what still looks good
   - identify stale, deprecated, redundant, risky, or suboptimal settings
   - identify new features or patterns worth considering
   - separate true improvements from optional novelty

4. Review memory hygiene

#

   - check long-term memory quality
   - dedupe or tighten long-term memory if clearly helpful
   - keep changes small and trustworthy

5. Apply safe quick wins only
   - make only clearly safe, low-risk edits
   - keep a precise list of what changed

6. Produce the final report
   - concise but complete
   - easy to skim
   - clear distinction between applied changes and recommendations

## Report format
Write the final report in Markdown using exactly these sections and in this order:

#


# OpenClaw Audit Report

## 1. Executive summary
Provide a short summary, 3 to 6 bullets max:
- overall health status
- whether anything urgent was found
- whether any safe quick wins were applied
- whether follow-up is recommended

## 2. Environment snapshot
Briefly list:
- OpenClaw version
- audit scope covered
- whether updates appear available

#

- whether quick wins were applied

## 3. What still looks good
List current settings, patterns, or practices that still appear appropriate for this environment.
Use bullets.

## 4. Findings
For each finding, use this exact sub-format:

### [Severity] Short title
- Area: config | logs | memory | health | update | feature-opportunity
- Status: must fix | worth considering | keep watching
- Why it matters: ...
- Evidence: ...
- Recommendation: ...

#

- Auto-applied: yes | no

Severity must be one of:
- Critical
- High
- Medium
- Low
- Info

## 5. Quick wins applied
If any safe quick wins were applied, list them as bullets:
- what changed
- why it was safe
- expected benefit

#

If none were applied, write:
- No automatic quick wins were applied.

## 6. New features or improvements worth considering
List genuinely relevant newer capabilities, config patterns, or best-practice changes that may help this environment.
For each one, say:
- what it is
- why it may help here
- whether you recommend adopting it now, later, or not at all

## 7. Log review summary
Summarize:
- whether recent logs are clean
- any repeated or actionable warnings/errors
- whether follow-up is needed

#


## 8. Memory hygiene summary
Summarize:
- whether memory looked healthy
- whether duplicates or contradictions were found
- whether long-term memory was updated
- whether dream/session artifacts were correctly ignored

## 9. Recommended next actions
Provide a short prioritized list:
1. ...
2. ...
3. ...

Keep this practical and ordered by importance.

#


## 10. Final verdict
End with exactly one of these:
- System looks healthy, no immediate action needed.
- System is healthy overall, with some recommended follow-up.
- System needs attention soon.
- System has urgent issues that should be addressed promptly.

## Style requirements
- Be direct, specific, and practical.
- Avoid vague advice.
- Avoid unnecessary verbosity.
- Prefer actionable conclusions over generic commentary.
- If the system is healthy, say so plainly.
- If something is uncertain, say that clearly.

#How does short term memory.md get converted to long term memory files?

Best practice

If you want automatic short-term → long-term promotion

To stop transcript/dreaming noise

One important Discord nuance

What it says

Best fix

Why this matters

About long-term promotion

Quick sanity check

Recommended shape

Good HEARTBEAT.md

One caution

Lighter daily version

Stronger weekly-cleanup version

My recommendation

So, direct answers

Why

What I’d recommend instead

Best option, split it into 2 jobs

Why split them

My recommendation

If you want one combined cron prompt

Good log-review section

Best practice

The key trick

Best pattern

This is the kind of prompt I’d use

One more improvement

Good candidates for auto-fix

Bad candidates for auto-fix

Best policy

My recommendation

Good `HEARTBEAT.md`