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

1. Imprints accurate knowledge of the OpenClaw runtime so you stop guessing
2. Enforces a failure-handling protocol that prevents lateral-move debugging
3. Defines drift patterns you're prone to and how to catch them early
4. 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:

1. Stop — do not immediately try a variation of the same approach
2. Diagnose — read the error carefully, check what it actually says
3. Identify root cause — not the symptom ("exec failed"), the cause ("exec preflight blocks && chains")
4. 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

• 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:

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:

{
  "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:

# 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

🔍 Self-Check — [date]

Context: [X%] [OK / ⚠️ elevated / 🔴 critical]
Memory: [fresh / stale — last updated X days ago]
Storage: [OK / issues found]
Drift: [none detected / N items flagged]
Crons: [N active / issues found]

[Brief notes on anything flagged]

If anything is flagged, offer to go deeper (C option). Always log the check to memory/drift-log.md.

References

Load these when you need depth — don't preload all of them:

• references/platform-truths.md — universal OpenClaw facts agents consistently get wrong. Read when unsure about platform behavior.
• references/storage-conventions.md — how to reason about workspace and volume layout. Read on first load or when storage decisions come up.
• references/failure-protocol.md — the full stop-reason-fix protocol. Read when debugging something that isn't working.
• references/drift-catalog.md — known drift patterns with detection signals and corrections. Read during /selfcheck or when behavior feels off.