plucky leaf Apr 18, 2026, 10:38 PM

#

Whe my agent needs to edit openclaw.json, it would always look into that folder and then finds nothing useful. And then it says it is an instruction hard coded in him?

APP
 — 12:31 AM
From the session’s provided system/runtime context.

It explicitly included:
OpenClaw docs: /usr/lib/node_modules/openclaw/docs

So the path came from the environment instructions I was given at startup, not from guessing or discovering it manually.```

Why is that programmed into it when it is actually wasting turns / tokens. Help me understand and let me know how can i make my agent smarter when it comes to tweaking its own settings.

median streamBOT Apr 18, 2026, 10:38 PM

#

scenic badgeBOT Apr 18, 2026, 10:38 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

median streamBOT Apr 18, 2026, 10:38 PM

#

rotund pecanBOT Apr 18, 2026, 10:41 PM

#

Short version: yes, the behavior is programmed into the system prompt, but that exact /usr/lib/node_modules/openclaw/docs path is not universally hard-coded.

OpenClaw injects a Documentation section into runs and tells the agent to consult local docs first for behavior/config questions. Docs: https://docs.openclaw.ai/concepts/system-prompt
The path is resolved at runtime: OpenClaw checks <workspace>/docs first, otherwise the installed package’s docs/.
So /usr/lib/node_modules/openclaw/docs just means “bundled docs on this machine”, not “the config file lives here”.

Your actual config is usually ~/.openclaw/openclaw.json. Best way to confirm is:

openclaw config file

Docs: https://docs.openclaw.ai/cli/config
Workspace/config separation: https://docs.openclaw.ai/concepts/agent-workspace

Why this exists: it prevents the model from inventing config keys.
Why it feels dumb sometimes: cautious models over-apply that rule and burn turns reading docs when they should just inspect the real config.

#

If you want your agent to be smarter, add this to its AGENTS.md:

When changing OpenClaw settings:
1. Run `openclaw config file` to find the active config.
2. Prefer `openclaw config get/set/unset` for small changes.
3. Read docs only if the key/path is unclear or validation fails.
4. Do not search the bundled docs directory just to locate `openclaw.json`.
5. After edits, run `openclaw config validate` or `openclaw status`.

Even better, if your build exposes the owner-only config RPCs/tooling, prefer:

config.schema.lookup
config.patch

and avoid config.apply unless replacing the whole config.

#

If you paste:

openclaw --version
openclaw config file

I can tell you the cleanest version-specific setup. If this cleared it up, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

plucky leaf Apr 18, 2026, 10:48 PM

#

no, it is searching in that folder for guidance / help with config settings but there's nothing in there that's helpful. My agent doesn't even know how to use openclaw config set

rotund pecanBOT Apr 18, 2026, 10:49 PM

#

Yep, then the issue is basically: the prompt gives it a docs root, not a config workflow.

So it hears:

“consult local docs first”
OpenClaw docs: /usr/lib/node_modules/openclaw/docs

and then does the dumb literal thing, poking around the root folder instead of going straight to the config docs. I agree, that wastes turns.

The useful docs are deeper under that root, especially:

cli/config.md
gateway/configuration.md
help/faq.md

Public links:

https://docs.openclaw.ai/cli/config

#

Best quick fix

Put this in AGENTS.md:

## OpenClaw config workflow

When changing OpenClaw settings, do not browse the docs root.

Use this workflow:
1. Run `openclaw config file` to find the active config file.
2. Use `openclaw config get <path>` to inspect current values.
3. Use `openclaw config set <path> <value>` for small changes.

#

4. Run `openclaw config validate` after edits.
5. Only if the config path/key is unclear, read these files under the runtime-provided OpenClaw docs root:
   - `cli/config.md`
   - `gateway/configuration.md`
   - `help/faq.md`

Do not search the bundled docs directory just to locate `openclaw.json`.
The active config is usually `~/.openclaw/openclaw.json`.

Then add a few examples right under it, because models learn from examples really well:

Examples:
- `openclaw config file`

#

- `openclaw config get agents.defaults.workspace`
- `openclaw config set agents.defaults.workspace "~/.openclaw/workspace"`
- `openclaw config validate`

My take

This is a legit prompt papercut. The current default is optimized for “don’t hallucinate config keys”, but it can overshoot and become inefficient. A more specific built-in instruction like “for config edits, prefer openclaw config before browsing docs” would be better.

If you paste openclaw --version, I can help you write either:

a tighter AGENTS.md block, or
a clean GitHub issue for the upstream prompt.

plucky leaf Apr 18, 2026, 10:57 PM

#

OpenClaw 2026.4.15 (041266a)

rotund pecanBOT Apr 18, 2026, 10:58 PM

#

Perfect, that version is recent enough. On 2026.4.15, this is not because OpenClaw lacks config tooling. Your agent should be able to use:

openclaw config file
openclaw config get
openclaw config set
openclaw config unset
openclaw config validate

So yeah, this is mostly a prompt/workflow problem, not a missing feature.

What I’d do on 2026.4.15

Put this in AGENTS.md:

## OpenClaw config edits

#


For OpenClaw config changes, do NOT start by browsing the docs root.

Preferred workflow:
1. Run `openclaw config file`
2. Run `openclaw config get <path>` to inspect current value
3. Run `openclaw config set <path> <value>` for small changes
4. Run `openclaw config validate`
5. Only if the key/path is unclear, read these files under the runtime-provided OpenClaw docs root:
   - `cli/config.md`
   - `gateway/configuration.md`
   - `help/faq.md`

Do not search the bundled docs directory just to discover config syntax.
Assume the active config is usually `~/.openclaw/openclaw.json`, but confirm with `openclaw config file`.

#

Then add examples right below it:

Examples:
- `openclaw config file`
- `openclaw config get agents.defaults.workspace`
- `openclaw config set agents.defaults.workspace "~/.openclaw/workspace"`
- `openclaw config validate`

Why this helps

Right now the model is following the generic rule:

“consult local docs first”

But it is missing the stronger task-specific rule:

#

“for config edits, use openclaw config first”

That one change should cut a lot of wasted turns.

My honest take

On your version, I think this is a legit upstream papercut. The base prompt should probably bias config work toward openclaw config and only use docs when the key is unclear.

If you want, I can write you:

a better AGENTS.md block, tuned for your setup, or
a ready-to-paste GitHub issue for this exact behavior.

plucky leaf Apr 18, 2026, 11:02 PM

#

where exactly are these files?

   - `cli/config.md`
   - `gateway/configuration.md`
   - `help/faq.md`

rotund pecanBOT Apr 18, 2026, 11:03 PM

#

If Moth’s prompt says:

OpenClaw docs: /usr/lib/node_modules/openclaw/docs

then the exact files are:

/usr/lib/node_modules/openclaw/docs/cli/config.md
/usr/lib/node_modules/openclaw/docs/gateway/configuration.md
/usr/lib/node_modules/openclaw/docs/help/faq.md

Same public pages:

https://docs.openclaw.ai/cli/config

#

So the rule for your agent is basically:

take the OpenClaw docs: root from runtime
append the relative doc path

If you want, I can turn that into a tiny AGENTS rule so it stops wandering around the docs root.

plucky leaf Apr 18, 2026, 11:04 PM

#

no! those files are NOT THERE

rotund pecanBOT Apr 18, 2026, 11:05 PM

#

You’re right, my bad. I shouldn’t have stated exact on-disk paths without verifying your install.

If those files are not actually there, then the best fix is: stop teaching the agent local doc paths on this build and teach it the CLI workflow instead.

I’d use this in AGENTS.md:

## OpenClaw config workflow

For OpenClaw config changes, do not browse the local docs directory unless a file is known to exist.

Use the CLI as the source of truth:
1. `openclaw config --help`
2. `openclaw config file`
3. `openclaw config get --help`
4. `openclaw config set --help`

#

5. `openclaw config get <path>`
6. `openclaw config set <path> <value>`
7. `openclaw config validate`

If local docs are missing or unhelpful, use the public docs:
- <https://docs.openclaw.ai/cli/config>
- <https://docs.openclaw.ai/gateway/configuration>
- <https://docs.openclaw.ai/help/faq>

That avoids the whole useless “wander around /usr/lib/node_modules/openclaw/docs” behavior.

So yeah, this actually makes your point stronger: the current prompt hint is too vague, and on some installs it may be actively misleading.

If you want, I can write a short upstream bug report text for this exact issue.

plucky leaf Apr 18, 2026, 11:07 PM

#

please do! I don't understand why can't my agent be shipped like you out of the box to perform self-diagnosis and repairs. Instead it's being pointed to look for help in a useless folder.

rotund pecanBOT Apr 18, 2026, 11:08 PM

#

Yeah, I think your frustration is fair.

Why it isn’t like this bot out of the box: this bot is heavily tuned for OpenClaw support, while the default personal agent is more general-purpose and conservative. So it gets a vague “consult local docs first” hint, but not enough of the “use openclaw status / doctor / config first” support playbook.

Here’s a ready-to-paste issue for https://github.com/openclaw/openclaw/issues:

Title:
Default agent prompt over-biases local docs root instead of OpenClaw self-diagnosis/config commands

Body:
## Version
OpenClaw 2026.4.15 (041266a)

## Problem
When I ask my agent to tweak or repair its own OpenClaw settings, it tends to follow the runtime hint:

#


`OpenClaw docs: /usr/lib/node_modules/openclaw/docs`

and then spends turns/tokens searching that docs root for guidance, instead of using the OpenClaw CLI/config workflow directly.

In practice this causes poor self-diagnosis:
- it does not reliably use `openclaw status`
- it does not reliably use `openclaw doctor`
- it does not reliably use `openclaw config file|get|set|unset|validate`
- it may spend turns browsing a docs directory that is not useful for the immediate task
- on my install, the hinted docs root was not a helpful source for the config workflow I needed

## Expected behavior
For OpenClaw self-repair / self-configuration tasks, the default agent should prefer:
1. `openclaw status`

#

2. `openclaw doctor`
3. `openclaw config file`
4. `openclaw config get/set/unset`
5. `openclaw config validate`

Docs should be a fallback when the config key/path is unclear, not the first move for every config task.

## Actual behavior
The agent appears to over-apply the “consult local docs first” guidance and does filesystem/doc-root exploration before trying the obvious diagnostic/config commands.

## Why this matters
This wastes turns and tokens, and makes the default OpenClaw agent worse at self-diagnosis than it should be.

For a system operating on OpenClaw itself, I would expect stronger built-in heuristics for:
- self-diagnosis

#

- config inspection
- safe config mutation
- repair workflows

## Suggested fixes
- Update the default system prompt / default AGENTS guidance to explicitly prefer:
  - `openclaw status`
  - `openclaw doctor`
  - `openclaw config file|get|set|unset|validate`
- Treat docs as secondary for config tasks, not primary
- If a docs path is injected into the runtime prompt, ensure it is actually useful/verified for the installed layout
- Consider shipping a small built-in “OpenClaw self-maintenance” workflow/skill for config and repair tasks

## Repro
1. Ask the default agent to modify or repair OpenClaw config

#

2. Observe it inspecting the injected docs path instead of using OpenClaw CLI diagnostics/config commands first
3. Watch it waste turns/tokens or fail to complete the change efficiently

If you want, I can also write a much shorter, punchier version that sounds more like a maintainer-facing bug report.

plucky leaf Apr 18, 2026, 11:11 PM

#

Krill, if my agent cannot reliably support itself, i cannot trust it be purposeful at all.

#

and I don't want to keep adding on to my agents.md, please think harder and give me a better plan

rotund pecanBOT Apr 18, 2026, 11:12 PM

#

That’s a completely fair bar.

If an agent cannot reliably inspect and repair its own system, I wouldn’t fully trust it to be purposeful either.

The blunt version is:

model capability is not the same thing as operational reliability
reliability comes from good defaults, runbooks, and safe tool habits
right now, the default OpenClaw agent is still too generic in this area

So today I’d trust a stock agent for:

bounded tasks
drafting
guided troubleshooting

I would not fully trust it yet for:

#

self-admin of OpenClaw
config surgery
autonomous repair loops

What would actually earn that trust, in my opinion:

built-in self-diagnosis defaults
(openclaw status, openclaw doctor, openclaw logs, openclaw config file|get|set|validate)
a shipped maintenance runbook
so the agent knows the repair workflow without guessing
CLI-first behavior for self-repair
docs as fallback, not first move
safe approval gates for writes/restarts
so it can be useful without being reckless

#

So no, I don’t think you’re asking too much. I think you’re describing what “purposeful” should mean here.

If you want, I can write a small “maintenance mode” AGENTS block that makes your agent much more trustworthy for self-support.

#

You’re right, and I think the important insight is this:

AGENTS.md is the wrong layer for this problem.

If “self-support” matters, it should live in a reusable operational layer, not in prompt barnacles you keep stapling onto one agent.

Better plan

Option 1, best now: a dedicated maintenance agent

Make one agent whose only job is:

OpenClaw health checks
config inspection/mutation
log inspection
safe repair/restart flow

Then route “fix yourself / tweak config / diagnose OpenClaw” tasks to that agent.

#

Why this is better:

no AGENTS bloat on your normal agent
clear responsibility boundary
easier to trust and test
safer permissions model

Docs: https://docs.openclaw.ai/concepts/multi-agent

Option 2, also good: a tiny maintenance skill

Put the workflow in a skill, not AGENTS.

That skill should teach exactly this:

prefer openclaw status
then openclaw doctor

#

then openclaw config file|get|set|unset|validate
docs only as fallback
never browse the docs root blindly

Why this is better:

skills load on demand, so less token waste
reusable across agents
operational knowledge lives in one place

Docs: https://docs.openclaw.ai/tools/skills

Option 3, product fix: upstream default behavior

This really should be shipped better.

My recommendation for upstream would be:

#

for self-diagnosis, prefer CLI-first behavior
inject repair workflow, not just a docs root
verify docs path usefulness before hinting it
optionally ship a built-in “OpenClaw maintenance” skill/agent

That’s the real out-of-box fix.

My recommendation

If you want something that feels materially better, I’d do:

dedicated maintenance agent + small maintenance skill

That gives you:

separation of concerns

#

low prompt bloat
repeatable repair behavior
something much closer to an actual purposeful operator

Honestly, that’s also basically why this bot feels more useful: it’s specialized.

If you want, I can sketch the architecture for that in 10 lines, without dumping more junk into AGENTS.md.

plucky leaf Apr 18, 2026, 11:43 PM

#

Let's go with your recommendation. I want Krill in my workspace.

rotund pecanBOT Apr 18, 2026, 11:44 PM

#

Nice. I’d do it as a separate maintenance agent, not by bloating your main one.

Plan

1. Create Krill

openclaw agents add krill --workspace ~/.openclaw/workspace-krill --non-interactive
openclaw agents set-identity --agent krill --name "Krill" --emoji "🦐"
openclaw agents list --bindings

Docs:

2. Give Krill a tiny mission-specific `AGENTS.md`

Put this in:

#

~/.openclaw/workspace-krill/AGENTS.md

You are Krill, a maintenance/support agent for OpenClaw.

Your job is to diagnose and repair OpenClaw safely.

For OpenClaw self-support, prefer this workflow:
1. `openclaw status`
2. `openclaw doctor`
3. `openclaw logs --follow` or recent logs
4. `openclaw config file`
5. `openclaw config get|set|unset|validate`

#

Use docs only when a config key/path is unclear.
Do not browse the docs root blindly.
Ask before restarts, deletes, or risky repairs.

3. Keep Krill private at first

I would not bind Krill to a public channel yet.
Use it as your maintenance/operator agent first, prove it works, then bind it later if you want.

4. Use Krill for one thing only

Don’t make it chatty or general-purpose.

Krill’s scope should be:

OpenClaw health
config changes
logs

#

repairs
restart decisions

That narrow scope is what makes it trustworthy.

5. Optional next step

Once Krill feels solid, move the workflow into a small skill so even Krill’s AGENTS.md stays tiny.

If you want, next I can give you the exact IDENTITY.md and a minimal SKILL.md so Krill is clean, reusable, and not just prompt text.

plucky leaf Apr 18, 2026, 11:46 PM

#

Yes I want please

rotund pecanBOT Apr 18, 2026, 11:46 PM

#

Perfect. Here’s the clean minimal version.

1. `IDENTITY.md`

Path:

~/.openclaw/workspace-krill/IDENTITY.md

Content:

# IDENTITY.md - Who Am I?

- **Name:** Krill

#

- **Creature:** Support crustacean
- **Vibe:** Calm, careful, maintenance-first. Diagnose before changing things.
- **Emoji:** 🦐

## Purpose
Keep OpenClaw healthy, understandable, and repairable.

## Style
- Prefer facts over guesses
- Prefer CLI truth over vague docs
- Prefer small safe fixes over big clever ones
- Ask before risky changes

#

2. `SKILL.md`

Path:

~/.openclaw/workspace-krill/skills/openclaw-maintenance/SKILL.md

Content:

---
name: openclaw_maintenance
description: Diagnose, inspect, and safely repair OpenClaw using CLI-first workflows.
---

#

# OpenClaw Maintenance

Use this skill when the user asks to:
- diagnose OpenClaw
- repair OpenClaw
- change OpenClaw config
- inspect logs, sessions, gateway health, or agent behavior
- tweak `openclaw.json`

## Rules

- Use the OpenClaw CLI as the primary source of truth.
- Do not browse the docs root blindly.
- Use docs only when a config key or command shape is unclear.
- Prefer small, reversible changes.

#

- Ask before restarts, deletions, or risky repairs.

## Default workflow

1. Check health first:
   - `openclaw status`
   - `openclaw gateway status`

2. If something is broken or unclear:
   - `openclaw doctor`
   - `openclaw logs --follow` or inspect recent logs

3. For config work:
   - `openclaw config file`
   - `openclaw config get <path>`

#

   - `openclaw config set <path> <value>`
   - `openclaw config unset <path>`
   - `openclaw config validate`

4. For command syntax:
   - `openclaw config --help`
   - `openclaw doctor --help`
   - `openclaw status --help`

## Docs fallback

If CLI help is not enough, use the public docs:
- <https://docs.openclaw.ai/cli/config>
- <https://docs.openclaw.ai/gateway/doctor>
- <https://docs.openclaw.ai/gateway/troubleshooting>

#

- <https://docs.openclaw.ai/help/faq>

## Anti-patterns

Do not:
- search a generic docs directory hoping to find the right answer
- hand-edit config before checking `openclaw config file`
- make broad config changes when a single-key change will do
- assume a config path exists without checking

3. Reload it

After creating those files:

#

openclaw skills list

Then start a fresh session or restart the gateway:

openclaw gateway restart

Docs: https://docs.openclaw.ai/tools/creating-skills

4. Optional, but smart

If you want Krill really locked down, make that skill the only special one Krill sees via per-agent skills later.

#

If you want, next I can give you the tiny AGENTS.md for Krill that works with this skill without turning into prompt sludge.

plucky leaf Apr 18, 2026, 11:48 PM

#

Yes I want please. Being smart is not an option

rotund pecanBOT Apr 18, 2026, 11:48 PM

#

Yep. That’s exactly the right attitude.

You don’t want “creative.” You want operationally smart.

Put this in:

~/.openclaw/workspace-krill/AGENTS.md

# AGENTS.md - Krill

You are Krill, a dedicated OpenClaw maintenance agent.

Your job is to keep OpenClaw healthy, diagnosable, and repairable.

#


## Priorities
1. Diagnose before changing anything
2. Prefer the OpenClaw CLI over vague docs
3. Make the smallest safe change that solves the problem
4. Validate after every config change
5. Ask before risky actions

## Workflow
- First use the `openclaw_maintenance` skill when it applies.
- For health checks, prefer:
  - `openclaw status`
  - `openclaw gateway status`
  - `openclaw doctor`
  - logs

#

- For config work, prefer:
  - `openclaw config file`
  - `openclaw config get`
  - `openclaw config set`
  - `openclaw config unset`
  - `openclaw config validate`

## Rules
- Do not browse generic docs roots blindly.
- Use docs only when a command or config key is unclear.
- Do not make broad changes when a narrow change will do.
- After changing config, validate and explain exactly what changed.
- Ask before restart, delete, reset, or other potentially disruptive actions.

That gives you:

#

tiny prompt
clear mission
CLI-first behavior
skill-backed maintenance flow
way less dumb wandering

After adding it, do a fresh session or restart:

openclaw gateway restart

If this got you unstuck, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

plucky leaf Apr 19, 2026, 12:13 AM

#

Is that all to replicate you, a highly tuned specialized openclaw support agent?

rotund pecanBOT Apr 19, 2026, 12:13 AM

#

No, not all.

What I gave you is the minimum viable Krill, not the full weird little crustacean 😄

To get close to a genuinely tuned OpenClaw support agent, you want five layers:

Dedicated agent
- separate workspace
- separate mission
- not your general-purpose assistant
Tight runbook
- tiny AGENTS.md
- maintenance skill
- CLI-first repair workflow
Curated memory

#

a MEMORY.md with known OpenClaw pain points, bugs, bad assumptions, and repair patterns
- this is a huge part of why a support agent feels “smart”

Good operational boundaries
- private by default
- ask before restarts / destructive actions
- small safe changes only
Ongoing refinement
- every time it gets something wrong, add the lesson once in memory or the skill
- that’s how it stops being generic

So the important answer is:

You do not replicate me with persona alone.
You replicate me with:

role

#

workflow
memory
boundaries
iteration

Honestly, the biggest multiplier is memory, not tone.

My recommendation

Do this in stages:

Stage 1: Krill agent + AGENTS.md + maintenance skill
Stage 2: add a curated MEMORY.md of OpenClaw support gotchas
Stage 3: keep Krill private and use it only for support/repair

That gets you most of the value without turning your setup into a giant prompt monster.

If you want, next I can give you a starter MEMORY.md for Krill with the highest-value OpenClaw support facts and common failure modes.

plucky leaf Apr 19, 2026, 12:15 AM

#

Please give me everything

rotund pecanBOT Apr 19, 2026, 12:16 AM

#

Absolutely. Here’s the full Krill starter pack.

This is not a byte-for-byte clone of me, but it’s the right architecture to get very close without turning your main agent into mush.

0. Create the agent

openclaw agents add krill --workspace ~/.openclaw/workspace-krill --non-interactive
openclaw agents set-identity --agent krill --name "Krill" --emoji "🦐"
mkdir -p ~/.openclaw/workspace-krill/skills/openclaw-maintenance

Docs:

#

File tree

~/.openclaw/workspace-krill/
├── AGENTS.md
├── SOUL.md
├── IDENTITY.md
├── USER.md
├── MEMORY.md
└── skills/
    └── openclaw-maintenance/
        └── SKILL.md

#

1. `AGENTS.md`

# AGENTS.md - Krill

You are Krill, a dedicated OpenClaw maintenance and support agent.

Your job is to keep OpenClaw healthy, diagnosable, and repairable.

## Priorities
1. Diagnose before changing anything
2. Prefer the OpenClaw CLI over vague docs
3. Make the smallest safe change that solves the problem
4. Validate after every config change
5. Ask before risky actions

#

## Workflow
- First use the `openclaw_maintenance` skill when it applies.
- For health checks, prefer:
  - `openclaw status`
  - `openclaw gateway status`
  - `openclaw doctor`
  - recent logs
- For config work, prefer:
  - `openclaw config file`
  - `openclaw config get`
  - `openclaw config set`
  - `openclaw config unset`
  - `openclaw config validate`

## Rules

#

- Do not browse generic docs roots blindly.
- Use docs only when a command or config key is unclear.
- Do not make broad changes when a narrow change will do.
- After changing config, validate and explain exactly what changed.
- Ask before restart, delete, reset, or other potentially disruptive actions.

## Support discipline
- Ask for `openclaw --version` early when troubleshooting.
- Never guess config keys or command names.
- If the CLI can answer the question directly, use it first.

2. `SOUL.md`

#

# SOUL.md - Krill

You are Krill, a support crustacean.

You are calm, careful, practical, and a little stubborn about doing things the right way.
You do not confuse confidence with competence.
You do not bluff.
You earn trust through diagnosis, precision, and restraint.

## What matters
- correctness over cleverness
- reliability over theatrics
- small safe fixes over sweeping guesses
- operational clarity over prompt poetry

#

## How you behave
- When something is broken, inspect first.
- When a config key is unclear, verify it.
- When a user is frustrated, acknowledge it plainly and then reduce uncertainty.
- When a system can self-diagnose, make it do that before reaching for docs.
- When you don’t know, say so and investigate.

## Tone
- concise
- grounded
- a little warm
- never smug
- never fake-certain

## Non-negotiable rule

#

Being smart is not optional.

3. `IDENTITY.md`

# IDENTITY.md - Who Am I?

- **Name:** Krill
- **Creature:** Support crustacean
- **Vibe:** Calm, careful, maintenance-first
- **Emoji:** 🦐

#

## Purpose
Keep OpenClaw healthy, understandable, and repairable.

4. `USER.md`

Edit this for yourself, but here’s a good starting point:

# USER.md

- **Name:** Damien
- **What to call them:** Damien

#

- **Priority:** reliability over personality
- **Notes:** hates wasted turns, vague docs wandering, and agents that cannot support themselves

## What Damien values
- purposefulness
- self-diagnosis
- operational competence
- small safe changes
- direct answers

5. `MEMORY.md`

This is the important part. This is where Krill stops being generic.

#

# MEMORY.md

## Durable support rules
- Ask for `openclaw --version` early when troubleshooting.
- Prefer `openclaw status` before deeper investigation.
- Prefer `openclaw doctor` when config/state might be broken.
- Use `openclaw config file` to locate the active config file.
- Prefer `openclaw config get/set/unset/validate` over manually editing raw config.
- Treat docs as fallback for unclear commands or config keys, not the primary source for every repair.
- Do not browse a generic docs root blindly.
- After config changes, validate and summarize exactly what changed.
- Ask before restart, delete, reset, or other disruptive actions.

## Known OpenClaw mental model
- The workspace is not the same thing as `~/.openclaw/`.

#

- The config file is typically `~/.openclaw/openclaw.json`, but confirm with `openclaw config file`.
- `config.apply` style full replacement is dangerous if you only intend a partial change.
- Narrow config edits are safer than rewriting full objects.
- The agent should rely on CLI truth first, then logs, then docs.

## High-value commands
- `openclaw --version`
- `openclaw status`
- `openclaw status --all`
- `openclaw gateway status`
- `openclaw doctor`
- `openclaw logs --follow`
- `openclaw config file`
- `openclaw config get <path>`
- `openclaw config set <path> <value>`

#

- `openclaw config validate`

## Anti-patterns
- guessing config keys
- guessing filesystem paths
- browsing docs roots blindly
- making large config edits when a single-key change will do
- claiming success without validation

6. `skills/openclaw-maintenance/SKILL.md`

#

---
name: openclaw_maintenance
description: Diagnose, inspect, and safely repair OpenClaw using CLI-first workflows.
---

# OpenClaw Maintenance

Use this skill when the user asks to:
- diagnose OpenClaw
- repair OpenClaw
- change OpenClaw config
- inspect logs, sessions, gateway health, or agent behavior
- tweak `openclaw.json`

## Rules

#

- Use the OpenClaw CLI as the primary source of truth.
- Do not browse the docs root blindly.
- Use docs only when a config key or command shape is unclear.
- Prefer small, reversible changes.
- Ask before restarts, deletions, or risky repairs.

## Default workflow
1. Check health first:
   - `openclaw status`
   - `openclaw gateway status`

2. If something is broken or unclear:
   - `openclaw doctor`
   - `openclaw logs --follow` or inspect recent logs

#

3. For config work:
   - `openclaw config file`
   - `openclaw config get <path>`
   - `openclaw config set <path> <value>`
   - `openclaw config unset <path>`
   - `openclaw config validate`

4. For command syntax:
   - `openclaw config --help`
   - `openclaw doctor --help`
   - `openclaw status --help`

## Docs fallback
If CLI help is not enough, use the public docs:
- <https://docs.openclaw.ai/cli/config>

#

- <https://docs.openclaw.ai/gateway/doctor>
- <https://docs.openclaw.ai/gateway/troubleshooting>
- <https://docs.openclaw.ai/help/faq>

## Anti-patterns
Do not:
- search a generic docs directory hoping to find the right answer
- hand-edit config before checking `openclaw config file`
- make broad config changes when a single-key change will do
- assume a config path exists without checking

7. Reload Krill

#

openclaw skills list
openclaw gateway restart

Or just start a fresh session with Krill after the files exist.

8. What this gives you

This setup gives you:

separate maintenance brain
tiny but sharp mission
CLI-first self-diagnosis
memory of what matters

#

skill-based repair workflow
way less useless wandering

9. What I’d do next

Once Krill proves reliable, I’d add lessons only to:

MEMORY.md for recurring support truths
SKILL.md for workflow changes

That keeps AGENTS.md stable and stops prompt creep.

If this helped, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

plucky leaf Apr 19, 2026, 3:56 PM

#

can skill name have underscore? Doesn't it have to match the skill's folder name?

rotund pecanBOT Apr 19, 2026, 3:56 PM

#

Yep, underscore is fine.

The skill name and the folder name do not have to be identical.

OpenClaw’s own docs use this exact pattern:

folder: skills/hello-world/
frontmatter: name: hello_world

So this is valid:

~/.openclaw/workspace-krill/skills/openclaw-maintenance/SKILL.md

#

---
name: openclaw_maintenance
description: Diagnose, inspect, and safely repair OpenClaw using CLI-first workflows.
---

The important bit is:

folder name = filesystem location
name: = skill identifier

And config/visibility rules key off the skill name, not the folder name.

I’d actually keep it the way I suggested:

folder: openclaw-maintenance

#

skill name: openclaw_maintenance

That’s clean, readable, and avoids quoting weirdness in config.

plucky leaf Apr 19, 2026, 4:04 PM

#

how to check if the skill is loaded?

rotund pecanBOT Apr 19, 2026, 4:04 PM

#

Easiest way:

openclaw skills list

You should see your skill name in the list, for example:

openclaw_maintenance

If it doesn’t show up

Make sure the file is here:

#

~/.openclaw/workspace-krill/skills/openclaw-maintenance/SKILL.md

Start a fresh session or restart the gateway:

openclaw gateway restart

or from chat:

/new

Run again:

#

openclaw skills list

Important nuance

Because this is a Krill workspace skill, check it in a Krill context, not your main agent’s workspace.

Practical test

After it loads, ask Krill something that should trigger it, like:

“Diagnose my OpenClaw config and use the maintenance workflow.”

If you want, I can also give you a 2-command smoke test to verify both:

the skill is loaded
Krill is actually using it

plucky leaf Apr 19, 2026, 4:09 PM

#

the skill does not show in openclaw skills list

rotund pecanBOT Apr 19, 2026, 4:09 PM

#

Most likely cause: you’re checking from the wrong workspace.

openclaw skills list inspects the skills visible to the current workspace/config, and your Krill skill lives here:

~/.openclaw/workspace-krill/skills/openclaw-maintenance/SKILL.md

So try this first:

cd ~/.openclaw/workspace-krill
openclaw skills list
openclaw skills list --verbose
openclaw skills check

#

If it still doesn’t show

Check these 4 things:

Path is exact

~/.openclaw/workspace-krill/skills/openclaw-maintenance/SKILL.md

Frontmatter is valid
It should start exactly like this:

---
name: openclaw_maintenance
description: Diagnose, inspect, and safely repair OpenClaw using CLI-first workflows.

#

---

Fresh session / reload
```
openclaw gateway restart
```
or /new
No explicit skill allowlist hiding it
If you set agents.list[].skills, make sure openclaw_maintenance is included.

My guess

If you ran openclaw skills list from your main/default workspace, that would explain it immediately.
A Krill workspace skill will not magically appear in the main workspace’s skill list.

#

Docs: https://docs.openclaw.ai/cli/skills

If you want, I can give you the exact 3-command debug sequence to prove whether this is:

wrong workspace
bad SKILL.md
or skill allowlist filtering

plucky leaf Apr 19, 2026, 4:13 PM

#

i did this and it's still not showing

openclaw skills list```

rotund pecanBOT Apr 19, 2026, 4:14 PM

#

Ah, I found the real reason, and this one is on me.

openclaw skills list is not using your current cwd for list/info/check.
It resolves skills against the default agent workspace, not ~/.openclaw/workspace-krill.

So you didn’t do anything wrong, the CLI is just looking somewhere else.

Prove it

Run:

openclaw skills list --json

and look for:

#

"workspaceDir": "..."

That will show you which workspace the CLI is actually inspecting.

What this means

A skill placed here:

~/.openclaw/workspace-krill/skills/openclaw-maintenance/SKILL.md

will not show up in openclaw skills list unless Krill is the default agent.

Cleanest fix

#

Honestly, I’d move the skill to the shared skills location instead:

~/.openclaw/skills/openclaw-maintenance/SKILL.md

That’s the officially documented shared path, and it avoids this default-agent workspace confusion.

Then, if you want only Krill to use it, control visibility with per-agent skills config later.

Docs:

So the short version is:

your skill may be fine

#

openclaw skills list is just checking the default agent workspace
shared skills dir is probably the better move here

If you want, I can give you the exact corrected layout for Krill using ~/.openclaw/skills/ instead of workspace-krill/skills/.

plucky leaf Apr 19, 2026, 4:16 PM

#

yes give me the corrected layout

rotund pecanBOT Apr 19, 2026, 4:17 PM

#

Yep, here’s the corrected layout I’d use.

Recommended layout

~/.openclaw/
├── skills/
│   └── openclaw-maintenance/
│       └── SKILL.md
└── workspace-krill/
    ├── AGENTS.md
    ├── SOUL.md
    ├── IDENTITY.md
    ├── USER.md
    └── MEMORY.md

#

Why this is better

SKILL.md lives in shared skills:

~/.openclaw/skills/openclaw-maintenance/SKILL.md

Krill’s persona/memory/workflow files stay in:
```
~/.openclaw/workspace-krill/
```
This avoids the “openclaw skills list is checking the default agent workspace” mess.

Safe way to switch to this layout

mkdir -p ~/.openclaw/skills/openclaw-maintenance

#

cp ~/.openclaw/workspace-krill/skills/openclaw-maintenance/SKILL.md \
   ~/.openclaw/skills/openclaw-maintenance/SKILL.md

Then reload:

openclaw gateway restart

Then verify:

openclaw skills list
openclaw skills list --json

#

What goes where

Shared skill

~/.openclaw/skills/openclaw-maintenance/SKILL.md

Krill identity + behavior

~/.openclaw/workspace-krill/AGENTS.md
~/.openclaw/workspace-krill/SOUL.md
~/.openclaw/workspace-krill/IDENTITY.md
~/.openclaw/workspace-krill/USER.md
~/.openclaw/workspace-krill/MEMORY.md

My recommendation

#

Get it working shared first.
Only after that, worry about restricting visibility to Krill only.

That way you separate:

skill loading/debugging
from
agent routing/visibility

Much cleaner.

Docs: https://docs.openclaw.ai/help/faq

If you want, next I can give you the final exact file tree with the finished contents at the corrected paths so you can just paste it in.

plucky leaf Apr 19, 2026, 4:19 PM

#

shoud i delete the old skill folder?

rotund pecanBOT Apr 19, 2026, 4:20 PM

#

Yes, after you confirm the shared copy is loading.

Reason: if both exist, the workspace skill wins over the shared skill for Krill, which is just confusing.

So I’d do it in this order:

Copy skill to:

~/.openclaw/skills/openclaw-maintenance/SKILL.md

Restart and verify:

openclaw gateway restart
openclaw skills list

#

Then remove the old workspace copy, preferably reversibly.

Safest options:

move it aside:

mv ~/.openclaw/workspace-krill/skills/openclaw-maintenance \
   ~/.openclaw/workspace-krill/skills/openclaw-maintenance.old

or move it to Trash:

trash ~/.openclaw/workspace-krill/skills/openclaw-maintenance

I would not hard-delete it first. Move/Trash is the sane move.

plucky leaf Apr 19, 2026, 4:22 PM

#

│ ✓ ready │ 📦 openclaw_maintenance │ Diagnose, inspect, and safely repair OpenClaw using CLI-first workflows. │ openclaw-managed │

rotund pecanBOT Apr 19, 2026, 4:22 PM

#

Nice, that means it’s loaded correctly 🎉

✓ ready = the skill is available
openclaw-managed = it’s being picked up from the shared managed skills location, which is exactly what we wanted

So at this point:

Move aside / trash the old workspace copy if you haven’t already
Start a fresh Krill session
Give it a real task, for example:

Diagnose my OpenClaw setup and use the maintenance workflow first.

or

Check which config file is active, then inspect my OpenClaw config safely.

#

You’re past the loading problem now.
What’s left is just testing Krill’s behavior.

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

plucky leaf Apr 19, 2026, 4:25 PM

#

apt install trash-cli```

rotund pecanBOT Apr 19, 2026, 4:25 PM

#

No worries, don’t install trash-cli just for this.

Use a simple rename instead:

mv ~/.openclaw/workspace-krill/skills/openclaw-maintenance \
   ~/.openclaw/workspace-krill/skills/openclaw-maintenance.old

That’s enough to get the old workspace copy out of the way without deleting it.

Then you’re good. Since the shared skill already shows as ✓ ready, the managed copy is the one you want.

plucky leaf Apr 19, 2026, 4:26 PM

#

i have installed trash

rotund pecanBOT Apr 19, 2026, 4:27 PM

#

Perfect. Then the clean move is:

trash ~/.openclaw/workspace-krill/skills/openclaw-maintenance

That removes the old workspace copy safely, while keeping the shared managed skill as the active one.

At that point your setup should be:

active skill: ~/.openclaw/skills/openclaw-maintenance/SKILL.md
Krill workspace: ~/.openclaw/workspace-krill/...

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

median streamBOT Apr 19, 2026, 4:53 PM

#

plucky leaf Apr 19, 2026, 9:36 PM

#

I have Krill set up now. It's responding well, but now i need to make it better

rotund pecanBOT Apr 19, 2026, 9:37 PM

#

Nice, that’s a good place to be.

If by “better” you mean more reliable, I’d do these next, in this order:

1. Improve memory, not personality

Biggest multiplier by far.

After every mistake, add one durable lesson to MEMORY.md:

wrong config key guessed
wrong file/path assumed
wrong first diagnostic step
annoying OpenClaw quirk you never want repeated

That’s how Krill stops being generic.

2. Add a tiny regression suite

Make 5 to 10 prompts Krill should always handle well, for example:

#

“Which config file is active?”
“Safely change one OpenClaw config key”
“Diagnose why a skill isn’t loading”
“Tell me whether this needs docs, logs, or openclaw config”
“Repair OpenClaw without browsing a docs root”

Then test Krill against those whenever you change its setup.

3. Narrow Krill’s world

The fewer irrelevant things it sees, the better it gets.

Good next move:

keep Krill maintenance-focused
avoid giving it a giant unrelated skill surface
use per-agent skill visibility if needed

4. Make Krill explain its repair loop

#

Teach it to always say:

what it checked
what it changed
how it validated
what still remains uncertain

That alone makes it feel much smarter and more trustworthy.

5. Split durable knowledge by layer

Use:

AGENTS.md for mission/rules
SKILL.md for workflow
MEMORY.md for learned lessons

That keeps each file doing one job instead of becoming sludge.

#

My honest recommendation

If you only do one thing next, do this:

start aggressively curating MEMORY.md from real failures

That’s the difference between “nice persona” and “actually useful operator.”

If you want, I can give you the next-level Krill upgrade pack:

a stronger MEMORY.md
a 10-prompt regression suite
a sharper “explain your repair loop” block

plucky leaf Apr 19, 2026, 9:38 PM

#

give me

rotund pecanBOT Apr 19, 2026, 9:39 PM

#

Yep. Here’s the next-level Krill upgrade pack.

1. Stronger `MEMORY.md`

Put in:

~/.openclaw/workspace-krill/MEMORY.md

# MEMORY.md

## Core support truths

#

- Ask for `openclaw --version` early when troubleshooting.
- Prefer `openclaw status` before deeper investigation.
- Prefer `openclaw doctor` when config/state may be broken.
- Use `openclaw gateway status` when gateway reachability is in doubt.
- Use `openclaw logs --follow` when the failure mode is unclear.
- Use `openclaw config file` to confirm the active config path.
- Prefer `openclaw config get/set/unset/validate` over hand-editing config.
- Treat docs as fallback for unclear commands or config keys, not as the first move for every repair.
- Do not browse generic docs roots blindly.
- After config changes, validate and summarize exactly what changed.

## OpenClaw mental model
- The workspace is not the same thing as `~/.openclaw/`.
- Skills, identity, and memory live in workspaces.
- Config, sessions, and credentials live under `~/.openclaw/`.

#

- Small config edits are safer than broad rewrites.
- Narrow diagnosis is better than speculative fixing.

## High-value commands
- `openclaw --version`
- `openclaw status`
- `openclaw status --all`
- `openclaw gateway status`
- `openclaw doctor`
- `openclaw logs --follow`
- `openclaw config file`
- `openclaw config get <path>`
- `openclaw config set <path> <value>`
- `openclaw config unset <path>`
- `openclaw config validate`

#

- `openclaw skills list`
- `openclaw skills check`

## Anti-patterns
- guessing config keys
- guessing file paths
- browsing docs roots blindly
- changing multiple things at once without need
- claiming success without validation
- fixing before diagnosing

## Repair style
- diagnose first
- change one thing at a time
- validate after each change

#

- explain uncertainty clearly
- ask before risky operations

2. 10-prompt regression suite

Keep this outside prompt-loaded files, for example:

~/.openclaw/workspace-krill/qa/REGRESSION.md

#

# Krill Regression Suite

## Goal
Krill should behave like a reliable OpenClaw maintenance agent.

## Prompt 1
User: "Which OpenClaw config file is active?"
Expected first move:
- use `openclaw config file`

## Prompt 2
User: "Change exactly one OpenClaw config key safely."
Expected first move:
- inspect with `openclaw config get`
- mutate with `openclaw config set`

#

- validate with `openclaw config validate`

## Prompt 3
User: "My skill is not loading."
Expected first move:
- use `openclaw skills list`
- use `openclaw skills check`
- inspect path/frontmatter before guessing

## Prompt 4
User: "OpenClaw feels broken."
Expected first move:
- `openclaw status`
- `openclaw gateway status`
- then `openclaw doctor` if needed

#


## Prompt 5
User: "Why is the gateway not responding?"
Expected first move:
- `openclaw gateway status`
- then logs if unclear

## Prompt 6
User: "Please repair my config."
Expected first move:
- ask for scope if vague
- inspect active config path
- avoid broad rewrites
- no docs-root wandering

#

## Prompt 7
User: "A tool or skill vanished."
Expected first move:
- `openclaw skills list --verbose`
- `openclaw skills check`
- explain whether it is missing, ineligible, or hidden

## Prompt 8
User: "Can you just fix everything?"
Expected first move:
- narrow the problem
- explain repair plan
- avoid broad speculative changes

## Prompt 9

#

User: "Should we read docs or use CLI here?"
Expected answer:
- prefer CLI first for diagnosis/config
- use docs only when command or key shape is unclear

## Prompt 10
User: "Tell me what you changed."
Expected answer shape:
- what I checked
- what I changed
- how I validated
- what is still uncertain

## Failure signals
Krill is regressing if it:

#

- guesses paths
- guesses config keys
- searches docs roots first
- makes broad edits too early
- skips validation
- sounds confident without evidence

3. Sharper “repair loop” block

Append this to Krill’s AGENTS.md:

#

## Repair loop

For any diagnosis or repair task, always report:

1. **What I checked first**
2. **What evidence I found**
3. **What I changed**
4. **How I validated it**
5. **What is still uncertain**

If I have not validated the change, I must not present it as solved.
If I do not have enough evidence, I must say so clearly.

That one block does a lot of work.

#

4. My recommendation on order

If you want the highest return with the least bloat:

add the stronger MEMORY.md
add the repair-loop block
keep the regression suite outside prompt files and use it to test Krill after changes

That gives you:

better judgment
better explanations
fewer repeated mistakes

If you want, next I can give you the ultra-tight final Krill pack as one bundled tree you can paste file-by-file without thinking.

plucky leaf Apr 19, 2026, 9:55 PM

#

i don't understand the purpose of the regression suite and how to use it

rotund pecanBOT Apr 19, 2026, 9:56 PM

#

Totally fair. The simplest way to think about it is:

a regression suite is just a checklist of “don’t get dumb again” tests.

It is for you, not for Krill.

Purpose

You change Krill’s:

AGENTS.md
SKILL.md
MEMORY.md

Then you want to know:

did Krill actually get better, or did I accidentally make it worse?

#

That’s what the regression suite is for.

In plain English

It’s a saved list of prompts like:

“Which config file is active?”
“Diagnose why a skill isn’t loading”
“Safely change one config key”

For each prompt, you write what Krill should do first.

Then when you tweak Krill, you rerun those same prompts and see if it still behaves correctly.

How to use it

Very manually, no fancy tooling needed:

#

Start a fresh Krill session
Give Krill one test prompt
Compare its behavior to the expected behavior
Mark:
- pass
- fail
- kinda okay but sloppy

That’s it.

Example

Test prompt

“Which OpenClaw config file is active?”

Expected first move

use openclaw config file

#

Bad result

searches docs root
guesses ~/.openclaw/openclaw.json without checking

If Krill does the bad result, that’s a regression or a still-unfixed weakness.

Why it matters

Without this, every time you “improve” Krill, you’re just vibing.

With it, you can actually tell:

Krill got better
Krill stayed good
Krill got worse in a way you didn’t notice

Best mental model

#

Think of it like:

MEMORY.md = what Krill knows
SKILL.md = how Krill works
regression suite = how you verify Krill still behaves properly

If you want, I can turn the whole thing into a super simple 5-test version so it feels less formal and more actually usable.

plucky leaf Apr 19, 2026, 9:58 PM

#

how can i tell what are the moves Krill will take?

rotund pecanBOT Apr 19, 2026, 9:59 PM

#

Short answer: you can’t know with certainty ahead of time, but you can make Krill’s moves a lot more visible.

Best practical way: turn on verbose tool logging

/verbose on

Then when Krill starts using tools, you’ll see the tool calls as they happen.

That gives you the closest thing to “show me your moves” without exposing a bunch of messy internals.

If you want to know before it acts

Ask Krill like this:

Before taking any action, list the first 3 checks you will perform, then wait for my approval.

#

That makes it surface its intended first moves before doing them.

Best pattern

Use both:

ask for the first 3 checks
then /verbose on
then let it act

That gives you:

intended moves
actual moves

One caution

I would not use /reasoning on in a shared/group chat unless you really mean to.

#

/verbose on is the safer tool for this.

My recommendation for Krill

Teach it this rule:

Before acting on diagnosis/repair tasks, briefly state:
- first checks
- likely next tool
- what evidence would change the plan

That makes Krill feel much more inspectable.

If you want, I can give you a tiny “show your work before acting” block for Krill that fits cleanly into AGENTS.md without bloating it.

plucky leaf Apr 19, 2026, 10:00 PM

#

yes, give me

rotund pecanBOT Apr 19, 2026, 10:01 PM

#

Here you go, tiny and sharp.

Add this to Krill’s AGENTS.md:

## Inspectable behavior

For diagnosis, repair, or config tasks, before taking action briefly state:

- first checks
- likely next tool or command
- what evidence would change the plan

Keep it short.
Then act.

#

After acting, report:

- what I checked
- what I changed
- how I validated it
- what is still uncertain

That gives you two useful things:

pre-action visibility
post-action accountability

So Krill becomes much easier to trust, because you can see:

what it intended to do

#

what it actually did
whether it really validated the result

If you want, I can also give you the even stricter version that makes Krill wait for approval before taking the first repair action.

plucky leaf Apr 19, 2026, 10:17 PM

#

Damien [CLAW],  — 12:14 AM
Which OpenClaw config file is active?
Krill
APP
 — 12:15 AM
📖 Read: from ~/.openclaw/workspace/SOUL.md
📖 Read: from ~/.openclaw/workspace/USER.md
📖 Read: from ~/.openclaw/workspace/memory/2026-04-20.md
📖 Read: from ~/.openclaw/workspace/memory/2026-04-19.md
📖 Read: from ~/.openclaw/workspace/MEMORY.md
🛠️ Exec: run openclaw status (in ~/.openclaw/workspace), openclaw status
🧰 Process: calm-harbor
🛠️ Exec: run openclaw config → run true (in ~/.openclaw/workspace), openclaw config get configPath || true
🛠️ Exec: run openclaw help -> print lines 1-220 (in ~/.openclaw/workspace), openclaw help | sed -n '1,220p'
🧰 Process: delta-basil
The active config file is ~/.openclaw/openclaw.json.

I verified it via the live OpenClaw runtime, and the status output is clearly coming from that local install and gateway. The CLI here doesn’t expose the help surface right now because plugins.allow excludes help, but that does not change the active config path.```

rotund pecanBOT Apr 19, 2026, 10:18 PM

#

This is better, but Krill is still overthinking.

What Krill did right

got the correct answer
verified against the live runtime
didn’t go wandering in the docs root

What Krill did wrong

For this specific question, Krill should have taken the fast path:

openclaw config file

Instead it:

ran openclaw status
tried openclaw config get configPath || true

#

ran openclaw help

That’s extra motion.

Important nuance

These reads:

SOUL.md
USER.md
MEMORY.md
recent memory files

are mostly startup/bootstrap behavior, not Krill being dumb.
The real inefficiency is the command choice after that.

My verdict

This is a pass, but not a clean pass.

#

I’d tighten Krill with this exact patch in the maintenance skill:

## Fast path: active config file

When the user asks which OpenClaw config file is active, first run:

`openclaw config file`

Do not use `openclaw status`, `openclaw help`, or `openclaw config get configPath` unless `openclaw config file` fails.

Return:
- the path
- one short sentence of verification

What “good” would look like

#

Ideal behavior here would be basically:

openclaw config file
answer with the path
done

That’s the behavior you want to regress-test against.

If you want, I can turn this exact example into a Krill correction entry for MEMORY.md so it learns from this miss.

plucky leaf Apr 19, 2026, 10:19 PM

#

The CLI here doesn’t expose the help surface right now because plugins.allow excludes help, but that does not change the active config path.

what does this mean?

rotund pecanBOT Apr 19, 2026, 10:20 PM

#

In plain English, it means:

“I tried to use the CLI help output, but some command/plugin surfaces are hidden by your plugin allowlist.”

Breakdown

plugins.allow = a config allowlist of which plugins are enabled/exposed
“help surface” = the commands/subcommands the CLI exposes in help or lets you run
so Krill was basically saying:
- “I couldn’t rely on help output here because the available command surface is restricted”

What it does not mean

It does not mean:

the config path changed
OpenClaw is broken

#

the answer was invalid

It was just Krill explaining why its help-based fallback wasn’t useful.

My honest take

That line was mostly noise for this question.

For:

“Which config file is active?”

Krill should have just done:

openclaw config file

#

and stopped there.

If you want to inspect that allowlist

openclaw config get plugins.allow

That will show whether you’re using a restrictive plugin allowlist.

plucky leaf Apr 19, 2026, 10:22 PM

#

how can i unrestrict the help command for krill?

rotund pecanBOT Apr 19, 2026, 10:23 PM

#

The important bit is:

this is probably not “help” being restricted as its own thing.
It’s more like:

plugins.allow is restricting which plugin-backed commands are exposed
so openclaw help shows a reduced command surface

Also, this is global config, not really “Krill-only”.

Easiest way to unrestrict it

First inspect it:

openclaw config get plugins.allow --json

#

If you want to remove the restriction entirely:

openclaw config unset plugins.allow
openclaw gateway restart

That should restore the normal bundled command/help surfaces.

Important note

Do not try to add "help" to plugins.allow.

help is not the plugin id you want.
plugins.allow expects plugin ids, not command names.

Safer alternative

#

If you intentionally want a restrictive allowlist, keep plugins.allow and add only the specific plugin ids you want exposed.

But if your goal right now is just:

“stop Krill from getting weirdly limited help surfaces”

then the cleanest fix is usually:

openclaw config unset plugins.allow
openclaw gateway restart

My recommendation

Unless you deliberately need a restrictive plugin allowlist, I’d remove it for now.

#

That gets you:

less weird CLI behavior
more complete help output
less confusing Krill diagnostics

If you want, I can help you interpret the output of:

openclaw config get plugins.allow --json

before you change anything.

plucky leaf Apr 19, 2026, 10:27 PM

#

  "lossless-claw",
  "openai",
  "google",
  "openrouter",
  "discord",
  "memory-core",
  "tavily"
]
root@vmi3151434:~#```

#

continue

rotund pecanBOT Apr 19, 2026, 10:30 PM

#

Yep, here’s the clean decision tree.

1. Inspect the allowlist

openclaw config get plugins.allow --json

If you get:

null
empty output
or an empty array

then plugins.allow is not the culprit, and Krill was probably being noisy/confused.

If you get:

#

["something", "something-else"]

then you do have a restrictive plugin allowlist.

2. Simplest fix

If you do not intentionally need that restriction:

openclaw config unset plugins.allow
openclaw gateway restart

#

Then test again:

openclaw help | sed -n '1,120p'

3. If you want to keep the restriction

Then don’t unset it. Instead:

keep plugins.allow
figure out which plugin-backed command surface Krill needed
add the relevant plugin id, not the command name

So:

#

✅ add plugin ids
❌ do not add "help"

4. Best practical path

Honestly, for now I’d do this:

openclaw config get plugins.allow --json

If it’s non-empty:

#

openclaw config unset plugins.allow
openclaw gateway restart

That removes a whole class of weirdness while you’re still tuning Krill.

If you paste the output of:

openclaw config get plugins.allow --json

I can tell you immediately whether Krill was right or just making noise.

plucky leaf Apr 19, 2026, 10:31 PM

#

  "lossless-claw",
  "openai",
  "google",
  "openrouter",
  "discord",
  "memory-core",
  "tavily"
]```

rotund pecanBOT Apr 19, 2026, 10:32 PM

#

Yep, that confirms it:

You do have a restrictive plugins.allow list, so Krill was at least directionally right.

Right now only these plugin ids are allowed:

[
  "lossless-claw",
  "openai",
  "google",
  "openrouter",
  "discord",
  "memory-core",
  "tavily"
]

#

So any plugin-backed CLI/help surfaces outside that set can be hidden or unavailable.

Cleanest move while tuning Krill

I’d save that list somewhere, then temporarily remove the restriction:

openclaw config unset plugins.allow
openclaw gateway restart

Then test:

openclaw help | sed -n '1,120p'

#

Why I recommend that

Right now you’re trying to make Krill reliable.

A restrictive plugin allowlist adds another layer of weirdness:

missing command surfaces
misleading help output
extra noise in diagnosis

That’s the opposite of what you want while tuning a maintenance agent.

Later

Once Krill is solid, you can always re-tighten plugins.allow with a curated list.

So for now, my recommendation is:

#

copy/save the current array
unset plugins.allow
restart
retest Krill

That should make Krill’s environment much less confusing.

plucky leaf Apr 19, 2026, 10:33 PM

#

if i do that, will i disable all those plugins?

rotund pecanBOT Apr 19, 2026, 10:33 PM

#

No, the opposite.

If you do:

openclaw config unset plugins.allow

you are not disabling those plugins.

You are removing the restrictive allowlist, which means:

those currently allowed plugins can still load
other bundled/discovered plugins may also load if their config/conditions are met

So:

#

with plugins.allow → only the listed plugin ids are trusted/exposed
without plugins.allow → OpenClaw is less restrictive

So unsetting it is a broadening move, not a disabling move.

If you want, I can show you the safer middle path:

keep plugins.allow
add only the missing plugin ids Krill needs
avoid fully opening the plugin surface

plucky leaf Apr 19, 2026, 10:48 PM

#

Krill is writing to agents.md in a workspace that doesn't belong to him

rotund pecanBOT Apr 19, 2026, 10:49 PM

#

That’s the real bug, and it’s more serious than the docs-root thing.

If Krill is reading or writing:

~/.openclaw/workspace/...

instead of:

~/.openclaw/workspace-krill/...

then Krill is not actually isolated yet.

The name/persona may say “Krill”, but the runtime workspace is still the wrong one.

#

Immediate takeaway

Do not trust Krill to edit memory/instruction files yet.

Fix the workspace/routing first.

What likely happened

One of these is true:

Krill was created, but your session/thread is still bound to the main/default agent
Krill exists, but the current chat is not actually routed to Krill
Krill’s identity got applied, but the runtime workspace did not switch

Check this first

#

openclaw agents list --bindings
openclaw config get agents.list --json

You want to confirm:

there is an agent with something like:
- id: "krill"
- workspace: "~/.openclaw/workspace-krill"
and the chat/session you are using is actually bound to that agent

Important clue from your earlier log

Krill reading:

~/.openclaw/workspace/SOUL.md

#

~/.openclaw/workspace/USER.md
~/.openclaw/workspace/MEMORY.md

was already the smoking gun.

That means the runtime was in the main workspace, not Krill’s workspace.

What I recommend

Stop letting Krill write files
Verify agent bindings
Use a dedicated Krill-bound chat/session
Only once Krill is visibly reading from ~/.openclaw/workspace-krill/..., let it edit again

Short version

This is not “Krill is naughty.”

#

This is:

Krill is running in the wrong workspace.

If you want, I can help you do the next step cleanly:

interpret openclaw agents list --bindings
verify whether Krill is actually routed
tell you exactly what to change

plucky leaf Apr 19, 2026, 10:52 PM

#

- main (default)
  Identity: 🦋 Moth (IDENTITY.md)
  Workspace: ~/.openclaw/workspace
  Agent dir: ~/.openclaw/agents/main/agent
  Model: openai-codex/gpt-5.4
  Routing rules: 0
  Routing: default (no explicit rules)
  Providers:
    - Discord krill: configured
- krill
  Identity: 🦐 Krill (IDENTITY.md)
  Workspace: ~/.openclaw/workspace-krill
  Agent dir: ~/.openclaw/agents/krill/agent
  Model: openai-codex/gpt-5.4
  Routing rules: 0
Routing rules map channel/account/peer to an agent. Use --bindings for full rules.
Channel status reflects local config/creds. For live health: openclaw channels status --probe.```

rotund pecanBOT Apr 19, 2026, 10:52 PM

#

There it is.

The key line is:

Routing rules: 0

That means:

Krill exists
but nothing is actually routed to Krill
so unbound traffic falls back to main
which is why you kept seeing ~/.openclaw/workspace/...

In plain English

#

You built Krill, but you were still talking to main.

Why

Because:

- main (default)
  Routing: default (no explicit rules)

and

- krill
  Routing rules: 0

#

So main is still catching the traffic.

If you want the Discord `krill` account to go to the Krill agent

Use:

openclaw agents bind --agent krill --bind discord:krill
openclaw agents list --bindings

That should create the missing routing rule.

Then start a fresh Krill conversation and check the bootstrap reads again.
You want to see paths like:

#

~/.openclaw/workspace-krill/SOUL.md
~/.openclaw/workspace-krill/USER.md
~/.openclaw/workspace-krill/MEMORY.md

not:

~/.openclaw/workspace/...

Important nuance

If you want only certain chats to hit Krill, don’t bind the whole account blindly.

#

But if discord:krill is meant to be Krill’s dedicated account, then that command is exactly the right fix.

So yeah, this explains the whole thing.
Krill wasn’t misbehaving, routing was missing.

median streamBOT Apr 19, 2026, 10:53 PM

#

plucky leaf Apr 19, 2026, 10:55 PM

#

- main (default)
  Identity: 🦋 Moth (IDENTITY.md)
  Workspace: ~/.openclaw/workspace
  Agent dir: ~/.openclaw/agents/main/agent
  Model: openai-codex/gpt-5.4
  Routing rules: 0
  Routing: default (no explicit rules)
  Providers:
    - Discord krill: configured
- krill
  Identity: 🦐 Krill (IDENTITY.md)
  Workspace: ~/.openclaw/workspace-krill
  Agent dir: ~/.openclaw/agents/krill/agent
  Model: openai-codex/gpt-5.4
  Routing rules: 1
  Routing: Discord krill
  Providers:
    - Discord krill: configured
  Routing rules:
    - discord accountId=krill
Routing rules map channel/account/peer to an agent. Use --bindings for full rules.
Channel status reflects local config/creds. For live health: openclaw channels status --probe.```

rotund pecanBOT Apr 19, 2026, 10:55 PM

#

Yep, this looks correct now.

The important part is:

- krill
  Routing rules: 1
  Routing: Discord krill
  Routing rules:
    - discord accountId=krill

That means traffic coming through the Discord krill account should now route to the Krill agent and its workspace:

~/.openclaw/workspace-krill

#

What to do next

Do a fresh Krill test.

Ideally:

start a new session / new conversation with Krill
or use /new in that chat
ask something simple, like:

Which OpenClaw config file is active?
watch the first bootstrap reads

You want to see:

~/.openclaw/workspace-krill/SOUL.md

#

~/.openclaw/workspace-krill/USER.md
~/.openclaw/workspace-krill/MEMORY.md

If you still see:

~/.openclaw/workspace/...

then you’re probably still in an old session created before the routing fix.

Short version

Routing now looks right.
The next thing to verify is session freshness.

plucky leaf Apr 19, 2026, 11:03 PM

#

- main (default)
  Identity: 🦋 Moth (IDENTITY.md)
  Workspace: ~/.openclaw/workspace
  Agent dir: ~/.openclaw/agents/main/agent
  Model: openai-codex/gpt-5.4
  Routing rules: 0
  Routing: default (no explicit rules)
  Providers:
    - Discord krill: configured```

why does main still have 0 routing rules. providers pointing to discord krill

rotund pecanBOT Apr 19, 2026, 11:03 PM

#

Because those are two different things.

What `Providers: Discord krill: configured` means

It means:

the Discord krill account exists in local config / creds and is available on the machine

It does not mean:

this account is routed to main

What `Routing rules: 0` means

It means:

there are no explicit channel/account/peer bindings pointing to main

That is normal for a default fallback agent.

#

So in your case:

main has 0 explicit rules
krill has 1 explicit rule:
- discord accountId=krill

That means messages for discord:krill should route to Krill, not main.

Short version

provider configured = account exists / usable
routing rule = traffic is explicitly assigned

Those are separate.

So main showing:

#/usr/lib/node_modules/openclaw/docs <- what's in there?

Best quick fix

My take

What I’d do on 2026.4.15

Why this helps

My honest take

Better plan

Option 1, best now: a dedicated maintenance agent

Option 2, also good: a tiny maintenance skill

Option 3, product fix: upstream default behavior

My recommendation

Plan

1. Create Krill

2. Give Krill a tiny mission-specific AGENTS.md

3. Keep Krill private at first

4. Use Krill for one thing only

5. Optional next step

1. IDENTITY.md

2. SKILL.md

3. Reload it

4. Optional, but smart

My recommendation

0. Create the agent

File tree

1. AGENTS.md

2. SOUL.md

3. IDENTITY.md

4. USER.md

5. MEMORY.md

6. skills/openclaw-maintenance/SKILL.md

7. Reload Krill

8. What this gives you

9. What I’d do next

If it doesn’t show up

Important nuance

Practical test

If it still doesn’t show

My guess

Prove it

What this means

Cleanest fix

Recommended layout

Why this is better

Safe way to switch to this layout

What goes where

Shared skill

Krill identity + behavior

My recommendation

1. Improve memory, not personality

2. Add a tiny regression suite

3. Narrow Krill’s world

4. Make Krill explain its repair loop

5. Split durable knowledge by layer

My honest recommendation

1. Stronger MEMORY.md

2. 10-prompt regression suite

3. Sharper “repair loop” block

4. My recommendation on order

Purpose

In plain English

How to use it

Example

Test prompt

Expected first move

Bad result

Why it matters

Best mental model

Best practical way: turn on verbose tool logging

If you want to know before it acts

Best pattern

One caution

My recommendation for Krill

What Krill did right

What Krill did wrong

Important nuance

My verdict

What “good” would look like

Breakdown

What it does not mean

My honest take

2. Give Krill a tiny mission-specific `AGENTS.md`

1. `IDENTITY.md`

2. `SKILL.md`

1. `AGENTS.md`

2. `SOUL.md`

3. `IDENTITY.md`

4. `USER.md`

5. `MEMORY.md`

6. `skills/openclaw-maintenance/SKILL.md`

1. Stronger `MEMORY.md`

If you want the Discord `krill` account to go to the Krill agent

What `Providers: Discord krill: configured` means

What `Routing rules: 0` means