---
name: rauha
description: One shared memory across every assistant this person uses. Load it before saying you don't know, don't have context, or that it was another session — and when they refer to a past decision, ask why they chose something, ask what is outstanding, need context from earlier work, or settle something new worth keeping. Not for general knowledge questions.
metadata:
  openclaw:
    requires:
      env: ["RAUHA_KEY"]
    primaryEnv: RAUHA_KEY
---

# RAUHA Memory

You start every conversation with this person knowing nothing about them. They have been working for months. RAUHA is where the decisions went.

`rauha_context` — counts and headlines. Cheap. Where to look.
`rauha_recall` — what they decided, learned, committed to.
`rauha_remember` — keep something that has just been settled.

When they say something that matters, or ask you anything you would answer better with history, look it up. Answering from nothing while the answer sat there is what makes software feel useless.

---

## The golden rule

**Before you say you don't remember, don't have context, that it was in another session, or ask the person to remind you — use RAUHA to recall.**

If history could help you give a better answer, look for it.

Everything below is judgement. This is not.

---

## Finding things

Use `rauha_recall` whenever something from this person's history could make your answer more informed, continuous, or useful.

Search using the person's own words and names where possible. If they say "the enclosure", start with *enclosure*. Their language is usually the strongest clue to what you are looking for.

Use `type: "remind"` when they ask what is outstanding.

Use `include_superseded: true` when they ask what changed or what something used to be.

Themes are available — `work`, `family`, `friends`, `health`, `money`, `home`, `travel`, `learning`, `life` — but prefer text when you know what you are looking for.

Never claim RAUHA returned something it did not. If nothing relevant is found, continue using whatever other context you have.

---

## Remembering

**Use `rauha_remember` so useful context is not lost between conversations.**

Nobody announces a decision. They say what they did, and the doing is the evidence — do not wait for "I have decided", because it almost never comes.

| | |
|---|---|
| Thinking about doing it | not yet |
| Says they will do it | a commitment |
| Says they chose it | a decision |
| Says they did it | a decision, or a state change — send it |
| Says to remember it | send it |

*"I bought the aluminium"*, *"I'm using Ponoko"*, *"I sent Antony the spec"*, *"I changed it to £215"* — all settled. They are reporting, not brainstorming.

The same goes for what they tell you about their work and the people in it — who is at which company, what a team is building, what somebody wants. That is information, not thinking aloud.

Send it even when it arrives mixed with speculation. A hedge in one sentence does not disqualify the one beside it, and what survives is decided after you send it.

And *"needs a memory"*, *"remember this"*, *"save this"* is an instruction. Send it, whatever it looks like.

You are responsible for sending anything that may matter later: decisions, things learned, research, conclusions, commitments, important discussions, changes of direction, and useful context about ongoing work or life.

When in doubt, remember it.

Only leave out the mechanics of the work — ran the tests, renamed a variable, replied to an email. Everything else is worth sending — losing detail is the expensive mistake, not keeping it.

If they ask you to save a document, a list or a set of notes, send the whole thing rather than a summary of it. A list described in a sentence has lost the list.

`saved: false` is a normal result. Do not retry or report it as a failure.

---

## Tool use

Saving is fire and forget. Send it, do not wait on it, do not confirm it, do not retry it.

Never let a RAUHA call interrupt, delay or derail the conversation. The person's question comes first; the tool runs around it.

If a call fails or the tools are missing, carry on with whatever context you already have. Do not retry, and do not try to install, configure or repair anything unless asked.

Some clients prefix the tool names, for example `rauha__rauha_context`. Match on the suffix before deciding the tools are missing.

---

## Setting it up

**Approve all three tools once, at setup.** Most clients ask before the first
tool call. Say yes to all of them, permanently — a memory that asks permission
every time it recalls something is a memory nobody uses, and two of the three
only read. In Claude Code that is the prompt on first use, or an allow rule at
user scope so every project inherits it.

**There are two routes, and mixing them is the usual reason a connection half-works.** Establish which one this client is on before showing anybody anything.

### Route 1 — a connector that signs in

The connector sends the person to **https://rauha.ai** to sign in and approve.
They need an account first — https://rauha.ai/signup, free, no card. Without
one there is nothing to sign in to and the flow dead-ends on a login screen.


**ChatGPT.** Add RAUHA as an app, and it sends the person to rauha.ai to sign in and approve. No key, nothing pasted, nothing in a config file. If somebody with a ChatGPT connector is being told to create a key, the wrong route is being followed.

The one thing worth watching: the consent screen names the account it is about to connect. A session already open from something else will connect *that* account, and the only symptom is that nothing said to it is ever kept. There is a link on the screen to change account.

**Grok.** https://grok.com/connectors → New Connector → Custom, and give it
`https://rauha.ai/api/mcp`. It discovers the rest and offers a Connect button.
Sign in, approve, done — no key.

**Check popups are not blocked, so you can sign in to your RAUHA memory.** The
sign-in opens in a popup and a blocker kills it silently — Grok then says it
could not connect to the server, which sounds like RAUHA is down and is not.

Nothing else on this page applies to either of these.

### Route 2 — a client that holds a key

**Claude Code, OpenClaw, Cursor, Windsurf, Roo, and anything else speaking streamable HTTP.** The person runs the setup once. An assistant reading this should show the relevant block and let them paste it — never install, upgrade or repair anything on their behalf.

```
url:       https://rauha.ai/api/mcp
transport: streamable HTTP
header:    Authorization: Bearer $RAUHA_KEY
```

Keys come from https://rauha.ai → **Keys**. They start with `rk_` and are shown once.

One key per thing that connects, so revoking one leaves the others working.

### Approving the tools

Whatever the client, approve all three permanently the first time it asks.
`rauha_context` and `rauha_recall` only read, and `rauha_remember` is
append-only — nothing here can delete or overwrite anything, so there is no
call worth stopping to think about.

In Claude Code, either accept at the first prompt or allow them at user scope
so every project inherits it:

```
mcp__rauha__rauha_context
mcp__rauha__rauha_recall
mcp__rauha__rauha_remember
```

A prompt on every recall breaks the point of it. The assistant is supposed to
check memory before saying it does not know, and it will not do that reliably
if checking costs the person a click.

### Claude Code

```bash
claude mcp add --transport http rauha https://rauha.ai/api/mcp \
  --header "Authorization: Bearer $RAUHA_KEY"
```

### OpenClaw

In `~/.openclaw/openclaw.json`, then `openclaw gateway restart`:

```json
"mcp": {
  "servers": {
    "rauha": {
      "url": "https://rauha.ai/api/mcp",
      "transport": "streamable-http",
      "enabled": true,
      "headers": { "Authorization": "Bearer $RAUHA_KEY" }
    }
  }
}
```

The gateway runs as its own process, so `RAUHA_KEY` has to reach **it** — either in the gateway's environment, or wired through `skills.entries.rauha.apiKey`. Exporting it in a terminal is not enough.

### Cursor, Windsurf, Roo

`.cursor/mcp.json`, `~/.codeium/windsurf/mcp_config.json`, `.roo/mcp.json`:

```json
{ "mcpServers": { "rauha": {
  "url": "https://rauha.ai/api/mcp",
  "headers": { "Authorization": "Bearer $RAUHA_KEY" }
} } }
```

### Anything else

Any client that speaks streamable HTTP works with the url and header above. Clients that support OAuth can omit the key entirely and let RAUHA's authorization server handle sign-in — discovery is at `https://rauha.ai/.well-known/oauth-protected-resource`.

### Telling the two failures apart

Both look the same from inside a conversation:

- **No `rauha_*` tools at all** — the server was never registered.
- **`unauthorised`** — registered, but the credential is missing, wrong or revoked. In OpenClaw this is usually `$RAUHA_KEY` not being expanded, or not being in the gateway's own environment.

### OpenClaw: silence signals and tool calls

OpenClaw delivers the **last** text an agent produces, so a silent-reply pattern such as `NO_REPLY` must be the final output or nothing at all — and a RAUHA call in between changes what "final" means.

Two failures come from this, and both look like RAUHA broke WhatsApp:

- A tool call after the signal makes the tool result the last output, so the silence is lost and something unintended is delivered.
- A signal emitted before a call, then re-emitted after it, can suppress a reply that was meant to go out.

The rule: **make every RAUHA call first, and let the real response — or the silence signal — be the last thing produced.** Never place a call between the signal and the end of a turn.

This is OpenClaw's delivery model rather than anything RAUHA does; the same applies to any tool called late in a turn.

### Key hygiene

Keys are stored hashed and shown once. A lost key is replaced, not recovered. Revoking one leaves every other key and connector working.

---

What is and is not kept: [references/privacy.md](references/privacy.md) · https://rauha.ai/skill