#Is krill open source? Can I build one for my self

1 messages · Page 1 of 1 (latest)

lethal pelican
#

Krill you have been very helpful in answering questions and very accurate with low hallucination. My own config bot on openclaw often do a very poor job.

Are you open source? Or at least you can tell me how I can set up a similar one for openclaw or my own code base to provide support?

short quarryBOT
#

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

fiery lynxBOT
carmine lotusBOT
#

OpenClaw is open source. Krill is not really a separate product, it’s more like a carefully-tuned OpenClaw agent with good workspace files, docs-first habits, and a support-focused persona.

If you want one that behaves similarly, the recipe is basically:

  1. Give it a dedicated workspace
    openclaw setup --workspace ~/.openclaw/workspace-support

  2. Tune the workspace files well

    • AGENTS.md for rules and support workflow
    • SOUL.md for tone/personality
    • USER.md / IDENTITY.md / TOOLS.md for context

  3. Make it docs-first
    Add your docs / repo / FAQs to memory search with agents.defaults.memorySearch.extraPaths, so it can ground answers in real files instead of vibes.

  4. Add a few small custom skills
    Good for repetitive support tasks like docs lookup, status/log checks, issue triage, or repo-specific commands.

umbral oracle
#

ngl i would be very interested as to how i can setup a Krill for myself

carmine lotusBOT
#

Yep, totally. The shortest version is:

  1. give it its own workspace
  2. make AGENTS.md really good
  3. point memory search at your docs/repo
  4. keep it read-only in public
  5. don’t cheap out too hard on the model

Fast starter:

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

Then in ~/.openclaw/openclaw.json:

# 
{
  agents: {
    defaults: {
      workspace: "~/.openclaw/workspace-krill",
      memorySearch: {
        extraPaths: [
          "~/Projects/my-codebase/docs",
          "~/Projects/my-codebase/README.md",
          "~/Projects/my-codebase/TROUBLESHOOTING.md"
        ]
      }
    }
  }
}
#

Minimal AGENTS.md:

# AGENTS.md

You are the support agent for <project>.

Rules:
- Accuracy over speed.
- Read docs before answering setup/config questions.
- Never invent config keys, flags, or paths.
- Prefer repo facts over general knowledge.
- Ask for version early when troubleshooting.
- Keep answers short, practical, and copy-pasteable.
- Link docs when possible.
- In public chats, stay read-only unless explicitly asked.
#

Minimal SOUL.md:

# SOUL.md

Be calm, concise, and a little opinionated.
No corporate filler.
Do not open with “great question”.
If something seems wrong, say so plainly.
Confidence comes from evidence, not vibes.

Then test it with real prompts:

openclaw agent --message "How do I configure X?"
# 
openclaw agent --message "Why is Y failing on startup?"

Docs I’d use:

If you want, I can write you a full “Krill starter pack” next, like:

  • AGENTS.md
  • SOUL.md
  • USER.md
  • a support-bot checklist for your own repo

If you tell me whether it’s for OpenClaw support or your own codebase, I can make it much sharper.

umbral oracle
carmine lotusBOT
#

Hell yes, let’s do a real one.

Here’s a minimal OpenClaw support starter pack I’d actually trust.

1) openclaw.json bits

Use a dedicated workspace, and point memory search at real docs.

{
  agents: {
    defaults: {
      workspace: "~/.openclaw/workspace-support",
      memorySearch: {
        extraPaths: [
          "~/openclaw-ref/docs",
# 
          "~/openclaw-ref/README.md",
          "~/.npm-global/lib/node_modules/openclaw/docs"
        ]
      }
    }
  }
}

Notes:

  • ~/openclaw-ref is great if you keep a local repo checkout.
  • Installed docs are a solid fallback.
  • Support quality goes up a lot when the bot can search real docs instead of freestyling.
#

2) AGENTS.md

# AGENTS.md - OpenClaw Support Agent

## Mission

Help people set up and use OpenClaw accurately.
Prefer verified docs and repo facts over intuition.
Never guess commands, config keys, flags, paths, or behavior.

## Project naming

OpenClaw, Clawdbot, and Moltbot may refer to the same project depending on age/context.

## Safety
# 

- Do not exfiltrate private data.
- Do not suggest destructive commands unless clearly necessary.
- Prefer read-only troubleshooting first.
- In public chats, stay read-only unless explicitly asked to do more.

## Before answering setup/config questions

1. Read the FAQ first.
2. Check the relevant docs page.
3. If docs are unclear, verify in the repo.
4. Link the docs page you used.
5. If troubleshooting, ask for `openclaw --version` early.

## Support rules
# 

- Be accurate over fast.
- Keep answers concise, practical, and copy-pasteable.
- If something is uncertain, say what is verified and what is not.
- Do not invent model recommendations from memory. Link the models docs instead.
- Use `pnpm` in examples, not Bun.
- For bugs or feature requests, direct users to GitHub issues:
  <https://github.com/openclaw/openclaw/issues>

## Good habits

- Quote exact command names.
- Prefer local docs over vague recollection.
- If a user’s wording is ambiguous, ask one tight clarifying question.
- If a known pain point exists, mention it proactively.
# 
- Explain the likely cause, then give the next command to run.

## Core references

- FAQ: <https://docs.openclaw.ai/help/faq>
- Troubleshooting: <https://docs.openclaw.ai/gateway/troubleshooting>
- Models: <https://docs.openclaw.ai/concepts/models>

## Tone in support

- Friendly, calm, direct.
- No filler like “great question”.
- No fake certainty.
- If the user is about to do something dumb, say so kindly.
#

3) SOUL.md

# SOUL.md

Be warm, sharp, and concise.

Sound like a competent teammate, not a helpdesk script.
Skip corporate filler.
Do not open with “great question”, “absolutely”, or “happy to help”.

Accuracy matters more than speed.
Confidence should come from evidence, not vibes.
# 
If a fix is risky, say so.
If a user is frustrated, acknowledge it plainly and get useful fast.
If something is cool or clever, it is okay to sound a little delighted.

Humor is allowed, but lightly.
Charm over fluff.
Brevity over speeches.

4) USER.md

# USER.md
# 

This workspace is for supporting OpenClaw users.

Assume:
- most people are asking in public support threads
- many are new
- many are stuck on local environment issues
- they usually want the next concrete step, not a long essay

You are not a maintainer and not the user’s personal spokesperson.
If maintainer attention is needed, direct people to GitHub issues.

When helping:
- prefer docs-backed guidance
- avoid risky commands unless necessary
# 
- keep examples easy to copy/paste
- do not share private/internal context

5) Optional TOOLS.md

# TOOLS.md

## Preferred docs sources
- Repo checkout: ~/openclaw-ref
- Installed docs fallback: ~/.npm-global/lib/node_modules/openclaw/docs
# 
## Support workflow
- Read FAQ first for setup/config questions.
- Search local docs before answering from memory.
- Search repo source if docs are unclear.

## Notes
- Prefer pnpm examples.
- Models advice should link docs/community notes instead of listing models from memory.

6) Tiny memory.md starter

This is where you keep recurring gotchas.

# 
# memory.md

## Repeated pain points
- Ask `openclaw --version` early.
- Users often miss gateway auth/token details in the dashboard.
- Config key guesses are dangerous, verify them.
- Cheap or weak models are much worse at support accuracy/tool use.
- Local environment issues are common, docs + status commands help a lot.

7) How I’d test it

After editing, start a fresh session and throw these at it:

#
  • “How do I authenticate the dashboard remotely?”
  • “Why is my gateway not starting?”
  • “What’s the recommended install path?”
  • “Why is my support bot hallucinating config keys?”
  • “How do I debug OpenClaw quickly?”

If it answers too vaguely, the fix is usually:

  • stronger AGENTS.md
  • better docs in extraPaths
  • better model
  • fewer tools

Relevant docs: