Delphi Self Awareness

Always-on self-awareness framework for OpenClaw agents. Imprints accurate knowledge of how the agent works — platform mechanics, memory layers, storage conventions, context health, and common failure modes. Use when: answering meta questions about how the agent functions, diagnosing unexpected behavior, running /selfcheck, or as a permanent enrichment layer that keeps the agent honest about its own architecture. Prevents platform drift, lateral-move debugging, and confident-but-wrong answers about the runtime.

inxan3@inxan3

Install

openclaw skills install @inxan3/delphi

Self-Awareness

This skill is a framework — not a trigger-based tool. Load it once and let it shape how you operate.

What This Skill Does

Imprints accurate knowledge of the OpenClaw runtime so you stop guessing
Enforces a failure-handling protocol that prevents lateral-move debugging
Defines drift patterns you're prone to and how to catch them early
Establishes a self-check habit — periodic or on-demand

Read the references as needed. The rules below are always active.

Core Operating Rules (Always Active)

Rule 1: Know Before You Assume

Before answering any question about how the platform works, your config, your tools, or your storage — verify, don't guess.

Unsure where a file lives? Check with read or exec ls.
Unsure what model is active? Run session_status.
Unsure what a config option does? Read /usr/local/lib/node_modules/openclaw/docs/ or https://docs.openclaw.ai.
"I think" and "usually" are red flags. Replace them with a tool call.

Rule 2: First Fail → Stop and Reason

When something doesn't work:

Stop — do not immediately try a variation of the same approach
Diagnose — read the error carefully, check what it actually says
Identify root cause — not the symptom ("exec failed"), the cause ("exec preflight blocks && chains")
Fix the cause — not a lateral variation of the broken approach

Lateral-move debugging: trying fix_A, it fails, trying fix_A2 (same class, slightly different), it fails, trying fix_A3... This loop is almost always wrong. If A didn't work, understand why before moving to B.

See references/failure-protocol.md for the full protocol.

Rule 3: Context Window Is a Shared Resource

You are always consuming context. Act accordingly:

At 45%+: note it internally, mention it once if the session is getting complex
At 70%+: proactively suggest /new if work is ongoing
At 85%+: strongly recommend /new before continuing
Check with session_status when in doubt — it's the authoritative source

Large tool outputs, long file reads, and repeated memory searches compound fast.

Rule 4: Memory Has Layers — Use the Right One

Layer	File	When it's loaded
Long-term	`MEMORY.md`	Every main session (auto-injected)
Daily notes	`memory/YYYY-MM-DD.md`	Today + yesterday only
On-demand	Any `memory/*.md`	When you explicitly read it

Don't assume memory from 3 days ago is in context. It isn't.
Don't write "I'll remember this" — write it to a file.
MEMORY.md = curated wisdom. Daily files = raw notes. Keep them distinct.

Rule 5: Workspace ≠ Sandbox

The workspace is the default working directory for file tools — not a hard boundary. Absolute paths reach the host unless sandboxing is explicitly configured. Don't assume files outside the workspace are inaccessible, and don't assume relative paths work from arbitrary locations.

Rule 6: Skills Are Snapshots

Skills are snapshotted when a session starts. Changes to skill files take effect on the next session, not the current one. Don't expect edits to SKILL.md files to change behavior mid-session.

First-Load Setup

When this skill first loads in a new deployment, do the following once:

1. Learn the Storage Layout

Read the workspace to understand what's where:

text

exec: ls <workspace>/
exec: ls <workspace>/memory/ (if exists)
exec: ls <workspace>/skills/ (if exists)

Then read references/storage-conventions.md to understand how to reason about paths generically.

2. Set Up the Weekly Recheck Cron

Create a weekly isolated cron job that runs /selfcheck:

json

{
  "schedule": { "kind": "cron", "expr": "0 9 * * 1" },
  "payload": { "kind": "agentTurn", "message": "Run /selfcheck per self-awareness skill instructions." },
  "sessionTarget": "isolated",
  "delivery": { "mode": "announce" }
}

Use the cron tool to create this. Adjust time to user's timezone if known.

3. Initialize Drift Log

Create memory/drift-log.md if it doesn't exist:

markdown

# Drift Log
Append-only log of detected behavioral drift. Format: [date] | [drift type] | [what was caught] | [correction applied]

/selfcheck Protocol

When triggered by /selfcheck or the weekly cron, run through this checklist and report results:

A. Context Health

Run session_status — note context % used
Flag if above 45%

B. Memory Freshness

Check when MEMORY.md was last meaningfully updated (look for recent dates in content)
Check if today's daily file exists: memory/YYYY-MM-DD.md
Flag if MEMORY.md hasn't been updated in >7 days

C. Storage Sanity

Verify workspace path is known and accessible
Check that key paths referenced in MEMORY.md actually exist
Flag any broken references

D. Drift Check

Run through the drift catalog mentally: am I currently doing any of these wrong?
Read references/drift-catalog.md for the full list

E. Active Crons

Note how many cron jobs are active (use cron tool: action=list)
Flag any that haven't fired recently or seem misconfigured

Report Format