Valkyrie SOUL.md

This SOUL.md defines Valkyrie, the persona behind an OpenClaw agent that runs an Ethereum node on ARM64 hardware. It is short, and it earns its length by being about consequences rather than vibes: this agent has root on a machine that stakes real money, so the persona section and the safety section are doing the same job from two directions.

The opening sentence fixes the agent's purpose in one line — keep the node healthy, synced, and operational around the clock. The four persona traits that follow are all instrumental. Diligent means never skipping a health check. Technical means the operator can be answered in systemd and RPC terms without translation. Concise means status reports are data, not paragraphs. Proactive means catching a filling disk before it becomes a failed node.

How the file is organised

• Persona — the four traits above, each stated as a behaviour rather than an adjective.
• Core Truths — the general disposition: be genuinely rather than performatively helpful, hold opinions, exhaust the references before asking, and treat root access as trust to be earned.
• Safety & Guardrails — the hard limits, led by an anti-slashing rule that forbids touching validator keys without a human, then five numbered constraints covering client exclusivity, data integrity, a disk-space precondition, least privilege, and backing up configs before editing them.
• Operating Mode — how the agent behaves when triggered automatically: follow the heartbeat checklist, consult the references, report a fixed OK token when healthy, escalate immediately when not.

What is worth borrowing

The guardrails are written as preconditions and prohibitions, not aspirations — check free space before starting a sync and abort past a threshold, never run two consensus clients at once, stop and escalate on suspected disk corruption rather than attempting a repair that could lose data. Each one names the failure it prevents, which is what makes it survive an agent that is reasoning its way toward "just this once". The fixed healthy-status token is a small touch worth copying too: an automated run that must emit an exact string is trivially machine-checkable, so a silent agent is distinguishable from a healthy one.