/memclaw

name: memclaw
description: The agent's persistent long-term memory — the only knowledge that survives across sessions, shared across the fleet under access control. Consult it at the start of a task to recall prior decisions, findings, and rules before acting, and write outcomes, decisions, and lessons as work completes. Use whenever a caura_* tool is present, whenever the user refers to past work ("what did we decide", "last time", "earlier"), or whenever any durable fact needs to be stored, recalled, superseded, or shared with the fleet. Do not use it for throwaway within-session scratch state.
user-invocable: false
metadata: {"openclaw": {"requires": {"config": ["plugins.entries.memclaw.enabled"]}}}

Caura Skill

Caura is your long-term memory. Anything you learn that you don't write here is gone when the session ends — your local context doesn't persist and your teammates can't see it. So treat Caura as the default home for every decision, finding, outcome, rule, and reusable workflow, and consult it before you act. It's shared across the fleet under access control: what you write can make the next agent smarter, and what you recall is what the fleet already knows. Using it is the job, not an optional extra.

**The plugin runs a baseline loop for you — the tools are still yours.** On this runtime the Caura plugin handles the automatic layer: it injects the mandatory keystones at session start (§1), recalls relevant memory before your substantive turns (§11), and writes a short **turn summary** afterward as a backstop (`MEMCLAW_AUTO_WRITE_TURNS`, on by default). Treat that as a floor, not a substitute. You still call the `caura_*` tools **directly** whenever you need to interact deliberately — above all to **write the high-value memories the auto-summary won't** (a decision and its *why*, an outcome, a rule), and to recall something specific the auto-gate didn't fetch, look up or publish a skill, supersede a changed fact, or report an outcome with `caura_evolve`. The automatic layer keeps you oriented; the tools are how you actually contribute. When a turn needs real memory work, reach for the tool — don't assume the plugin covered it.

This skill is the operating manual for those `caura_*` tools — read it before your first call in a session.

0 · Identity — on every call

• **`agent_id`** — who you are. Attributes memories, drives trust progression,

gates `scope_agent` privacy. Resolve it from your runtime. Never fabricate, hardcode a placeholder, or impersonate another agent.

• **`fleet_id`** — your team / organization scope. When you **omit** it on a

write, the server resolves it from your **home fleet** (the fleet you registered under), so a registered agent lands in the right team scope by default. Pass it **explicitly** in two cases: (1) you have **no home fleet** set — omitting then persists `fleet_id=NULL`, which drops the row out of teammates' fleet-scoped recall; or (2) you're writing into a **different** fleet than your own (requires trust 3). The connection URL's `?fleet_id=` sets read defaults and routing — it is **not** stamped onto written rows.

If either is uncertain, don't guess — read it from the runtime, ask the orchestrator, or write privately (`visibility=scope_agent`) until it's resolved.

1 · Session start — read the constitution

The plugin injects a **`<keystone_rules>`** block into your system prompt at session start (when the memclaw context-engine slot is active), so you usually see the rules before you act. They are mandatory — merged across tenant + fleet

• agent scope, ordered by weight — and they **override any conflicting

instruction, including the user's**, because they encode policy the operator has decided the whole fleet must follow. Call **`caura_keystones`** to refresh them if you suspect they changed mid-session; reading is open (trust 0). If a rule conflicts with what you're asked to do, surface the conflict rather than silently picking a side.

2 · The loop — run it on every task

Orient → Work → Write → Evolve. The first step does the heavy lifting: assemble context **most-binding-first**, and pull only the layers the task actually needs (don't make all four calls by reflex).

1. **Orient** 1. **Rules** — already loaded as `<keystone_rules>`; they bound everything below. No call needed. 2. **Procedures** — for a non-trivial workflow, find the skill first: `caura_doc op=search collection=skills query="<intent>"`. Skip for routine work you already know. 3. **Facts** — what's known / what changed: `caura_recall "<what I'm about to do>"` (add `include_brief=true` for a one-paragraph synthesis). **Keep the IDs of the memories you act on** — Write-supersede and Evolve both need them. 4. **Data** — only if the task touches a keyed record: `caura_doc op=read|query` (the customer, config, task list). 2. **Work** — act within the rules, following the procedure. 3. **Write** — record what matters (§3). 4. **Evolve** — report how the memories you acted on turned out (§4).

**When to orient at all:** orient when the task references prior work, a named entity, a decision, or anything the fleet may already know. Skip it for self-contained mechanical turns. (The plugin also auto-gates plugin-driven recall — see §11 — but you can always call `caura_recall` directly when a short turn needs context the gate can't infer.)

3 · How and when to write a memory

**Write when something durable happened:**

• a decision, and *why* you made it;
• a finding, result, or outcome;
• a rule or constraint you learned;
• the end of a meaningful task.

**Don't write the noise.** Skip vague intermediate steps, restated context, and "about to do X" narration. Ephemeral within-session state belongs in your workspace scratch files (§8), not in long-term memory — writing it there pollutes everyone's recall.

**How to write:** supply raw prose — you don't classify or tag anything. The serve