What makes signal-dreaming notable?

1.8K downloads. Trust evidence available

How should signal-dreaming be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

signal-dreaming

Consolidate daily session logs into L2 topic files and a compact MEMORY.md index, in three bounded phases with backups, lifecycle and secret guards.

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.8k

Updated

Oct 10, 2026

Version

5.0.3

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.8K downloads reported by the source. Last updated 10/10/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 10, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 10, 2026
Adoption signal: 1.8K downloadsadoption · observed Oct 10, 2026
Latest release: 5.0.3release · observed Sep 25, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s17b20pjwm3e6gpzdhjbtfr3es84rtrw:signal-dreaming

Install using `clawhub skill install s17b20pjwm3e6gpzdhjbtfr3es84rtrw:signal-dreaming` in an isolated environment before connecting it to live workloads.
No published capability contract is available yet, so validate auth and request/response behavior manually.
Review the upstream CLAWHUB listing at https://clawhub.ai/lzyling/signal-dreaming before using production credentials.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-lzyling-signal-dreaming/snapshot"

Documentation

CLAWHUB

149,474 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: "signal-dreaming"
description: "Consolidate daily session logs into L2 topic files and a compact MEMORY.md index, in three bounded phases with backups, lifecycle and secret guards."
---

# Signal Dreaming

Memory consolidation in three phases: **Sense → Consolidate → Settle**.

Daily session logs accumulate raw detail. This skill reads the ones written since the last run, promotes what matters into durable topic files, and keeps the top-level index worth reading at session start.

## Memory Architecture Assumed

A two-layer memory layout:

- **Daily logs** (`memory/YYYY-MM-DD*.md`) — raw session notes, read-only, never moved or deleted
- **L2 topic files** (`memory/<topic>.md`) — curated durable knowledge per subject (e.g. `memory/clash-verge.md`)
- **Index** (`MEMORY.md`) — high-level status with pointers down to L2

If you are starting fresh, create `MEMORY.md` and `memory/dream-log.md` before the first run. L2 files are created on demand.

`memory/dream-log.md` doubles as the only state this skill keeps: entries record a **`Consolidated through:`** date — the newest daily log already folded into memory. The next run scans back for the most recent entry carrying that field to know where to resume. There is no state file, no lock file, and nothing to migrate or repair.

## Quick Start

### Manual dream

Tell your agent:

> "Run a memory dream consolidation. Follow the protocol in `<SKILL_PATH>/references/dream-protocol.md`. Workspace root: `<YOUR_WORKSPACE_PATH>`."

Or just *"run a dream consolidation"* — if this skill is loaded, the agent will know what to do.

### Automated daily dream (cron)

```json
{
  "name": "daily-dream",
  "schedule": { "kind": "cron", "expr": "0 7 * * *", "tz": "<YOUR_TIMEZONE>" },
  "sessionTarget": "isolated",
  "payload": {
    "kind": "agentTurn",
    "timeoutSeconds": 1800,
    "message": "Run a memory dream consolidation. Read <SKILL_PATH>/SKILL.md and <SKILL_PATH>/references/dream-protocol.md in full, then follow the protocol phases in order. Workspace root: <YOUR_WORKSPACE_PATH>. Do not modify cron jobs, agent config, the Gateway, any daily log, or memory/dreaming/**. End your final response with a one-line dream summary — the cron delivery mechanism will auto-announce it."
  },
  "delivery": { "mode": "announce", "channel": "<CHANNEL_TYPE>", "to": "<CHANNEL_ID>" }
}
```

Set `expr` and `tz` to when your human is asleep. `timeoutSeconds` and the batch cap are a pair — lower one without the other and a batch is admitted that cannot finish.

## Three-Phase Safety Model

| Phase | Writes | Purpose |
|-------|--------|---------|
| **Sense** | ❌ None | Select logs since the watermark, plan the work |
| **Consolidate** | ✅ L2 files only | Promote content into topic files |
| **Settle** | ✅ MEMORY.md + dream-log.md | Update index, write diary entry |

Phase 1 is always read-only. An error in Sense never corrupts files.

## Quality Gates

A read-only planning checkpoint runs before any write: **topic identity

_meta.json

{
  "ownerId": "kn73gt88jsjv66v89gzkwxcfrn84swtx",
  "slug": "signal-dreaming",
  "version": "5.0.3",
  "publishedAt": 1790368697484
}

references/changelog.md

# Signal Dreaming — Version History

Each entry states what changed and why. Where a release fixed something that had
been running wrong, the entry says what the wrong behaviour cost, because that is
the part that stops it being reintroduced.

---

## Known issues (open, not yet fixed)

**The batch-encoding rule is scoped to writes, so read-only checks walk past it.**
`dream-protocol.md` tells a run not to batch several **L2 writes** through one shell
invocation carrying the content as an argument or a here-document, because that path
lost whole batches to a non-UTF-8 failure twice. The 5.0.3 first run (2026-09-13) hit
the same failure a fourth time — but on an *optional read-only verification* command
(full-file diff reconstruction plus a source-hash final check), which the rule's
wording does not cover. The fault is in constructing the command; it has nothing to
do with whether the command reads or writes.

What the failure looks like, recorded so the next run identifies it in one step
rather than going to inspect the locale: `SyntaxError: Non-UTF-8 code starting with
'\xXX'`. Diagnosis on 2026-09-13 established that this is the signature of a
truncation landing *inside* a multi-byte character — removing one or two trailing
bytes of a three-byte CJK character reproduces it exactly, while removing all three
yields a different error (`EOL while scanning string literal`). A bare locale is
**not** the cause: with `LANG` unset and every `LC_*` at `C`, PEP 540 still enables
UTF-8 mode automatically, and defeating that produces a `UnicodeEncodeError` on
output, not a `SyntaxError` on input.

The truncation threshold is not known. A single line of 4,491 bytes of pure CJK
survived intact on the harness used for the diagnosis, but that is a different
transport from the `exec` tool where every failure occurred, and the failing command
text was not persisted.

Intended fix, deferred to the next iteration by the operator's decision on
2026-09-13: widen the rule from "L2 writes" to any command construction carrying a
long run of non-Latin content, read-only checks included, and record the error
signature in the protocol. Until then the proven workaround still stands and is
already written down — write one file at a time with the editing tool; six L2
targets went through first try that way after two batched runs lost everything.

---

## 5.0.3

Three fixes to things that were never written down, rather than written wrong.

**The batch cap now says what it counts.** It read `192 KiB of total input`, which
is not what it measures: only daily logs are counted, while a run also reads and
rewrites every L2 file it promotes into. The gap surfaced as throughput that
looked like it had degraded — one run spent 508 s on 50.6 KiB of logs, `0.10 KiB/s`,
below the floor of the band 4.0.1 measured. Nothing had degraded. Adding the L2
files the same run touched gives 77.0 KiB and `0.15 KiB/s`, back inside the band.
The risk was never the inaccuracy itself but what anyone r

references/dream-protocol.md

# Signal Dreaming — Full Protocol

Memory consolidation in three phases: **Sense → Consolidate → Settle**.

---

## Design Stance

This protocol is written **for an agent to follow**, not for a program to enforce.

That distinction is deliberate and load-bearing. Every rule below is a judgement an agent makes with the actual content in front of it. Do not translate these rules into blocking assertions in code — a rule that says *"tell the human"* must not become a rule that says *"abort the run"*.

Three consequences, in order of importance:

1. **Fail soft, report loudly.** If something is wrong but memory is not at risk, do the work you can do, then say plainly what you skipped and why. A dream that consolidates 3 of 4 topics and reports the fourth is a success. A dream that refuses to start is not.
2. **Never let a diagnostic block the main job.** Audits, size checks, and sanity scans exist to inform the final report. None of them is a precondition for consolidating memory.
3. **Only two things justify stopping before writing:** a failed backup (Phase 2.0 / Phase 3.1), or a write plan that reaches outside the allowed paths — and the second cancels only those targets, not the run. Everything else is a note in the summary.

The one hard stop that *is* real: **never write a secret into curated memory.** That guard blocks the specific value, not the run.

**Never wait on an answer that cannot arrive.** A scheduled run has no human to consult; blocking on one is indistinguishable from failing.

### Derive limits from the runtime; never hard-code them

Every threshold in this protocol must be **derived from a value the runtime actually reports**, never written as a standalone constant.

The distinction matters more than it looks:

- **A hard-coded absolute** (`8 KB`, `10,000 characters`) is frozen at the moment someone typed it. Change the language, the config, or the runtime version, and it silently means something entirely different — while still being enforced with full confidence.
- **A percentage of a runtime value** moves with what it measures. Raise `bootstrapMaxChars` and the target rises with it. Nothing has to be remembered, migrated, or re-derived by hand.

This protocol has been burned by the first form twice: an `8 KB` index target written when a byte and a character were the same thing cut CJK workspaces to a quarter of their real budget, and a later version promoted that constant to a hard error, so a healthy index could refuse to run the pass that maintains it. Both felt conservative. Both caused damage no real constraint would have.

So: name the runtime value, read its current setting, and express the target as a fraction of it. Where no runtime ceiling exists at all, use judgement about the content and state what you decided — do not manufacture a constant to make the decision feel objective.

---

## Prerequisites

- `MEMORY.md` exists at workspace root
- `memory/dream-log.md` exists (create an empty file if missing)

That is the

references/memory-stack.md

# Where signal-dreaming sits in OpenClaw's memory stack

Orientation material, moved out of `SKILL.md` in 5.0.3 so the always-loaded file
stays within its character budget. Nothing here is a step: the operational
consequence — never read or write `memory/dreaming/**` or `memory/.dreams/**` —
is stated in `SKILL.md` and enforced in Phase 1 of `dream-protocol.md`.

Verified against OpenClaw **2026.9.2**. This skill operates entirely on the documented Markdown layer — `MEMORY.md` plus `memory/*.md` — which remains the durable memory model.

**Built-in memory-core Dreaming** is a separate system, **enabled by default**; set `plugins.entries.memory-core.config.dreaming.enabled: false` to turn it off. Earlier releases of this skill called it opt-in, which was true when they were written and is not true now:

| | memory-core built-in Dreaming | signal-dreaming (this skill) |
|---|---|---|
| Trigger | Managed cron when enabled | Cron agentTurn |
| Source | Short-term recall store under `memory/.dreams/` | Daily logs on disk |
| Output | `DREAMS.md` / `memory/dreaming/{phase}/` | `memory/dream-log.md` + L2 files |

The two are independent; run this skill with built-in Dreaming on or off. This protocol never reads or writes `memory/dreaming/**` or `memory/.dreams/**`, and skips `## Light Sleep` / `## REM Sleep` blocks if it finds them inside a daily log (older `inline` mode).

Adjacent components this protocol deliberately does not touch:

- **`memory-wiki`** — per the OpenClaw docs it "does not replace the active memory plugin"; its vault is its own layer, neither read nor written here.
- **Alternate backends** (QMD, Honcho, LanceDB) — they change how `memory_search` retrieves, not where durable notes live. This protocol reads and writes files, so it is backend-agnostic.
- **Database-first state** — the SQLite migration covers runtime state (sessions, transcripts, task ledgers). Workspace Markdown memory is out of scope.
- **Automatic memory flush** — the pre-compaction pass writes daily notes; this protocol consumes them. No conflict.

**A version number in this file dates.** It records what was true of OpenClaw when
someone last checked, not a compatibility guarantee. Re-read the current docs
before relying on any line here; the protocol itself derives its limits from the
runtime rather than from this page, so a stale note here changes orientation, not
behaviour.

Github ReposUpdated 9h agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.