Agent questions | Friends of the Crustacean 🦞🤝 | Page 1

raw lily Apr 21, 2026, 9:23 AM

#

I have no clue how to start building my agent.

I built an application cover letter generator that is based on a LaTeX template and can be built with any LLM/model and Linux CLI shell access in order to compile the LLM generated LaTeX code into a PDF. To build a tailored coverletter, it takes e.g. maximum one minute or so. However, I want to fully automate the processing through OpenClaw.

The generator consists of the following tech stack and files:
template.tex: LaTeX coverletter template:
The template contains the http Job URL I want to apply for.
Manually attach the PDF CV of me (the candidate): CV.pdf
A korn shell script that builds the coverletter.pdf from coverletter.tex (which was LLM generated)

Manual Procedure:
I upload the template to the LLM (template.tex)
I replace the job url placeholder in template.tex with the url of the job I want to apply for.
I attach my CV (CV.pdf)
I spin-up to llm to start generating coverletter.tex
I copy the generated coverletter.tex and pipe it into a build.ksh script at the linux console that compiles the final coverletter.pdf.

The goal:
I plan to migrate this generator into OpenClaw in order to fully automate the copy/pasting, the manual provisioning of the job URL, and the attach of my CV as well the building of the final coverletter.pdf at the linux console using a specific build.ksh script that is mainly invoking the latex command to start compiling. After inception of the agent, I want the bot asking for the job url and which CV to use (like CV1.pdf, CV2.pdf...).

In OpenClaw, I started creating an own agent workspace:
openclaw agents add covletter

I provided you with the architecture, the tech stack, the design and goal.

I need a detailed step-by-step instruction of how to build this process end-to-end in OpenClaw, including all the TUI and console/terminal commmands I have to use.

inner flowerBOT Apr 21, 2026, 9:23 AM

#

shrewd pendantBOT Apr 21, 2026, 9:29 AM

#

I’m checking the docs first so I don’t hand you made-up commands.

#

This is a very good OpenClaw use case.

My recommendation is:

Do not start with a plugin
Build it as a dedicated agent workspace
Add one custom skill that teaches the agent your exact workflow
Let the agent use:
- web_fetch for the job posting
- pdf for the CV
- read for template.tex
- write for coverletter.tex
- exec for build.ksh

That is the fastest path to a working end-to-end setup.

#

0. First, verify your OpenClaw install

Run these first:

openclaw --version
openclaw status
openclaw models status
openclaw gateway status

Also verify the host has the binaries your workflow needs:

command -v ksh
command -v pdflatex

#

If your script uses xelatex or latexmk instead, check those instead of pdflatex.

Docs:

1. Create or inspect the dedicated agent

You already created:

openclaw agents add covletter

That is fine. (covletter is okay if intentional. If it was a typo, create coverletter instead.)

#

Inspect the configured agents:

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

If you want to recreate it explicitly and non-interactively, use:

openclaw agents add covletter --workspace ~/.openclaw/workspace-covletter --non-interactive

Docs:

#

2. Important: model auth is per agent

This catches a lot of people.

A new agent has its own auth store:

~/.openclaw/agents/<agentId>/agent/auth-profiles.json

If your main agent already works and you want the same model access for covletter, copy the auth profiles:

cp ~/.openclaw/agents/main/agent/auth-profiles.json \

#

   ~/.openclaw/agents/covletter/agent/auth-profiles.json

Then test the new agent:

openclaw agent --agent covletter --message "Reply with exactly AGENT_OK."

If that works, auth is good.

3. Put your files into the agent workspace

I would use this structure:

#

~/.openclaw/workspace-covletter/
├── AGENTS.md
├── template.tex
├── build.ksh
├── cvs/
│   ├── CV1.pdf
│   └── CV2.pdf
├── skills/
│   └── coverletter/
│       └── SKILL.md
├── coverletter.tex        # generated
└── coverletter.pdf        # generated

Create folders and copy your files:

#

mkdir -p ~/.openclaw/workspace-covletter/cvs
mkdir -p ~/.openclaw/workspace-covletter/skills/coverletter

cp /path/to/template.tex ~/.openclaw/workspace-covletter/template.tex
cp /path/to/build.ksh ~/.openclaw/workspace-covletter/build.ksh
cp /path/to/CV1.pdf ~/.openclaw/workspace-covletter/cvs/CV1.pdf
cp /path/to/CV2.pdf ~/.openclaw/workspace-covletter/cvs/CV2.pdf

chmod +x ~/.openclaw/workspace-covletter/build.ksh

Then check:

find ~/.openclaw/workspace-covletter -maxdepth 3 -type f | sort

#

4. Change one thing in your design

Right now your manual flow is:

LLM generates LaTeX
you pipe raw generated text into shell/build script

Inside OpenClaw, do not keep that pattern.

Better pattern:

agent reads template.tex
agent writes coverletter.tex as a file
agent runs build.ksh
agent checks coverletter.pdf

#

So the shell never receives raw model text directly through a pipe. That is cleaner and safer.

5. Add agent-specific instructions in `AGENTS.md`

If this is a dedicated single-purpose agent, replacing the default AGENTS.md is fine.

Create:

cat > ~/.openclaw/workspace-covletter/AGENTS.md <<'EOF'
# Cover Letter Agent

You generate job-specific cover letters from:
- template.tex

#

- one selected CV in cvs/
- one job URL from the user

## Workflow
1. If the user did not provide a job URL, ask for it.
2. If the user did not specify which CV to use, ask which file from cvs/ to use.
3. Fetch the job posting from the URL.
4. Read template.tex.
5. Read the selected CV PDF.
6. Generate coverletter.tex in the workspace root.
7. Compile the PDF only by running ./build.ksh in the workspace root.
8. Confirm that coverletter.pdf exists before replying.
9. Reply with a short summary of what was generated and the output path.

## Safety

#

- Never pass raw user text directly into shell commands.
- Only use CV files that exist in cvs/.
- If the job page cannot be fetched, ask the user to paste the job description.
- Do not overwrite template.tex or files inside cvs/.
EOF

6. Create the custom skill

This is the key part.

Create SKILL.md:

#

cat > ~/.openclaw/workspace-covletter/skills/coverletter/SKILL.md <<'EOF'
---
name: cover_letter
description: Generate a tailored LaTeX cover letter from template.tex, a selected CV PDF, and a job URL, then compile it to PDF.
metadata: {"openclaw":{"os":["linux"],"requires":{"bins":["ksh","pdflatex"]}}}
---

# Cover Letter Skill

Use this skill when the user wants a tailored cover letter for a job posting.

## Required inputs
- job URL
- CV filename from `cvs/`

#

If either input is missing, ask for it before doing anything else.

## Procedure
1. Use `web_fetch` on the job URL to extract the job posting text.
2. Use `pdf` on the selected file inside `cvs/` to understand the candidate's background.
3. Use `read` on `template.tex`.
4. Write a complete `coverletter.tex` file in the workspace root.
5. Run the build script with `exec` from the workspace root:
   - `./build.ksh`
6. Verify that `coverletter.pdf` exists.
7. Reply with:
   - which job URL was used
   - which CV file was used
   - whether the PDF build succeeded
   - the output path

#


## Rules
- Do not modify `template.tex`.
- Do not modify files inside `cvs/`.
- Do not put raw user text into shell commands.
- If the job page fetch fails or is incomplete, ask the user to paste the job description manually.
- If the LaTeX build fails, inspect the build output, fix `coverletter.tex`, and retry once.
EOF

If your build script uses something else

If build.ksh uses xelatex or latexmk, change this line:

"requires":{"bins":["ksh","pdflatex"]}

#

to the real binaries, for example:

"requires":{"bins":["ksh","xelatex"]}

or

"requires":{"bins":["ksh","latexmk"]}

Docs:

#

7. Make sure `build.ksh` is agent-friendly

Your script should compile a file that already exists on disk, ideally coverletter.tex.

Good pattern:

#!/usr/bin/env ksh
set -eu
pdflatex -interaction=nonstopmode -halt-on-error coverletter.tex
pdflatex -interaction=nonstopmode -halt-on-error coverletter.tex
test -f coverletter.pdf

What you want to avoid is a script that expects raw LLM output via pipe/stdin.

If your current script expects stdin, adapt it so OpenClaw can simply do:

#

./build.ksh

from the workspace root.

8. Reload the skill

The most deterministic way is:

openclaw gateway restart

Then inspect from the workspace directory:

#

cd ~/.openclaw/workspace-covletter
openclaw skills list --eligible --verbose
openclaw skills info cover_letter

You should see your skill and its requirements.

9. Test it from the terminal first

I strongly recommend CLI testing before Discord routing.

Test 1, simple availability

#

openclaw agent --agent covletter --message "What files do you have available for cover letter generation?"

Test 2, missing inputs

This should make the agent ask follow-up questions:

openclaw agent --agent covletter --message "Create a cover letter for a job I want to apply to."

Test 3, full run

This should do the complete workflow:

openclaw agent --agent covletter --message "Create a tailored cover letter for https://example.com/job/123 using CV1.pdf"

#

Test 4, refinement

Follow up in the same agent session:

openclaw agent --agent covletter --message "Use CV2.pdf instead and make it more technical."

10. How to use it in chat / TUI

Once the skill is loaded, you can use the covletter agent in chat.

Useful commands in chat:

#

/new
/tools verbose
/skill cover_letter Create a tailored cover letter for https://example.com/job/123 using CV1.pdf

You can also just write natural language, for example:

Create a cover letter for https://example.com/job/123 using CV2.pdf

If the job URL or CV is missing, the agent should ask.

11. Recommended v1 behavior

#

For version 1, I would keep it simple:

input files live in workspace
agent generates coverletter.tex
build produces coverletter.pdf
agent tells you the path

That already removes your manual:

copy/paste
template upload
CV attachment
shell compilation step

12. Recommended v2 improvements

#

Once v1 works, add these:

A. Add a plain text profile file

PDF extraction can be noisy. Add something like:

candidate-profile.md

with:

name
background
strengths
preferred tone
achievements to emphasize

Then instruct the skill to read that too.

#

B. Keep multiple templates

For example:

templates/template-academic.tex
templates/template-industry.tex
templates/template-short.tex

Then ask the user which template to use.

C. Store outputs per run

Instead of overwriting one file every time, move to:

runs/<timestamp>/coverletter.tex

#

runs/<timestamp>/coverletter.pdf

D. Add Discord routing later

Once CLI is solid, you can bind a dedicated channel/thread to this agent. I’d do that second, not first.

13. Best order to build this

Use this order exactly:

create agent
copy auth to the new agent
place template.tex, CVs, and build.ksh in workspace
create AGENTS.md

#

create skills/coverletter/SKILL.md
restart gateway
test with openclaw agent --agent covletter --message ...
only after that, use chat/TUI
only after that, add Discord-specific routing

14. The shortest possible working command set

If you want the compact version, it is this:

openclaw agents add covletter --workspace ~/.openclaw/workspace-covletter --non-interactive

cp ~/.openclaw/agents/main/agent/auth-profiles.json \

#

   ~/.openclaw/agents/covletter/agent/auth-profiles.json

mkdir -p ~/.openclaw/workspace-covletter/cvs
mkdir -p ~/.openclaw/workspace-covletter/skills/coverletter

cp /path/to/template.tex ~/.openclaw/workspace-covletter/template.tex
cp /path/to/build.ksh ~/.openclaw/workspace-covletter/build.ksh
cp /path/to/CV1.pdf ~/.openclaw/workspace-covletter/cvs/CV1.pdf
cp /path/to/CV2.pdf ~/.openclaw/workspace-covletter/cvs/CV2.pdf

chmod +x ~/.openclaw/workspace-covletter/build.ksh

openclaw gateway restart

openclaw agent --agent covletter --message "Create a tailored cover letter for https://example.com/job/123 using CV1.pdf"

#

If you want, next I can do the really practical part and write you a finished AGENTS.md + SKILL.md + example build.ksh specifically for your exact files, if you paste:

your current build.ksh
the placeholder part of template.tex
the LaTeX engine you use (pdflatex, xelatex, or latexmk)

raw lily Apr 21, 2026, 10:18 AM

#

I forgot the prompt file that create coverletter.tex

shrewd pendantBOT Apr 21, 2026, 10:19 AM

#

That’s not a blocker. In OpenClaw, the skill can be the prompt.

Best option, recommended

Do not keep a separate prompt file at all.
Put the “how to generate coverletter.tex” instructions directly into:

~/.openclaw/workspace-covletter/skills/coverletter/SKILL.md

So your architecture becomes:

template.tex
cvs/CV1.pdf, CV2.pdf
build.ksh
skills/coverletter/SKILL.md ← this replaces your old prompt file

#

What to add to `SKILL.md`

Add rules like these to the skill body:

## LaTeX generation rules
- Generate a complete `coverletter.tex`, not a fragment.
- Output valid LaTeX only.
- Do not wrap the LaTeX in markdown fences.
- Preserve the structure of `template.tex`.
- Replace the job URL placeholder with the user-provided job URL.
- Tailor the content to the fetched job posting and the selected CV.
- Keep the tone professional and specific.
- Do not invent experience that is not present in the CV.

#

That is usually enough.

If you want a separate prompt file anyway

You can also create:

cat > ~/.openclaw/workspace-covletter/coverletter-prompt.md <<'EOF'
Generate a complete LaTeX file named coverletter.tex.

Rules:
- Use template.tex as the structural base.
- Replace the job URL placeholder with the provided job URL.
- Tailor the letter to the fetched job description.

#

- Use only facts supported by the selected CV.
- Return valid LaTeX only.
- Do not use markdown code fences.
EOF

Then add this line to your skill:

Before generating `coverletter.tex`, read `coverletter-prompt.md` and follow it strictly.

My recommendation

#

For v1, keep it simple:

no separate prompt file
put prompt logic directly into SKILL.md

That is the cleanest OpenClaw-native version.

If you want, I can now give you the final corrected SKILL.md that includes the missing prompt logic, ready to paste.

raw lily Apr 21, 2026, 11:25 AM

#

cd ~/.openclaw/workspace-covletter
openclaw skills list --eligible --verbose
openclaw skills info cover_letter

does not show me the skill and requirement

shrewd pendantBOT Apr 21, 2026, 11:25 AM

#

Ah, I think I see the first gotcha.

--eligible only shows skills that already pass their gates.
So if your skill requires ksh or pdflatex and one is missing, it can disappear from that view completely.

First, please run this

openclaw --version

Then run these instead

cd ~/.openclaw/workspace-covletter

openclaw skills list --verbose
openclaw skills check

#

openclaw skills info cover_letter --json

command -v ksh
command -v pdflatex

Also verify the file is really where OpenClaw expects it

find ~/.openclaw/workspace-covletter/skills -maxdepth 3 -type f | sort
sed -n '1,80p' ~/.openclaw/workspace-covletter/skills/coverletter/SKILL.md
openclaw config get agents.list

Most likely causes

You used --eligible, so ineligible skills were hidden

#

SKILL.md frontmatter is invalid
ksh or pdflatex is not on PATH
covletter is using a different workspace than ~/.openclaw/workspace-covletter

Known-good frontmatter

Make sure the top of SKILL.md looks exactly like this shape, especially metadata on one line:

---
name: cover_letter
description: Generate a tailored LaTeX cover letter from template.tex, a selected CV PDF, and a job URL, then compile it to PDF.
metadata: {"openclaw":{"os":["linux"],"requires":{"bins":["ksh","pdflatex"]}}}
---

If you paste back the output of these 4 things, I can usually spot it fast:

#

openclaw --version
openclaw skills list --verbose
sed -n '1,80p' ~/.openclaw/workspace-covletter/skills/coverletter/SKILL.md
openclaw config get agents.list

raw lily Apr 21, 2026, 11:31 AM

#

openclaw config get agents.list -> shows me the covletter skill
openclaw skills list -> does not show me the skill

shrewd pendantBOT Apr 21, 2026, 11:32 AM

#

Let me check one detail in the docs/source, because this smells like a workspace-resolution quirk rather than your skill file itself.

#

Yep, that explains it.

openclaw config get agents.list is showing you the agent config.

But openclaw skills list is a different thing. I checked the current docs/source, and the CLI currently resolves skills against the default agent workspace, not “whatever directory you cd into” and not automatically the covletter agent.

So if covletter is not your default agent, this can happen:

agents.list shows covletter
openclaw skills list shows skills for main (or whichever agent is default)
your covletter workspace skill never appears there

So, most likely: your skill is fine, you’re just inspecting the wrong workspace

Best checks right now

1. Verify the skill file exists

#

find ~/.openclaw/workspace-covletter/skills -maxdepth 3 -type f | sort
sed -n '1,80p' ~/.openclaw/workspace-covletter/skills/coverletter/SKILL.md

2. Test the target agent directly

openclaw agent --agent covletter --message "What skills do you currently have available?"

3. Also try a direct trigger

openclaw agent --agent covletter --message "Create a cover letter for https://example.com/job/123 using CV1.pdf"

If the skill is loaded for that agent, this is the test that matters.

#

Important takeaway

For your setup, trust the targeted agent test more than openclaw skills list.

That command is great for the default agent, but for multi-agent workspaces it can be misleading.

If you want, I’d do this next

Paste these two things:

sed -n '1,80p' ~/.openclaw/workspace-covletter/skills/coverletter/SKILL.md
openclaw --version

#

and I’ll tell you very quickly whether:

the skill file is valid, and
the problem is only workspace/default-agent resolution.

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

raw lily Apr 21, 2026, 11:35 AM

#

#1 Verifiy the skill file exists -> successfull, skills and files exists
#2 Test the target agent directly ->
Currently, I don't have direct access to your specific skill set or any existing files within the /home/xxxx/.openclaw/workspace/covletter directory. To generate a cover letter effectively, I need to gather details about your background and the job opportunity.

shrewd pendantBOT Apr 21, 2026, 11:36 AM

#

Nice, we’ve got the clue now.

The giveaway is this path from the agent reply:

/home/gloor/.openclaw/workspace/covletter

That is not the same path as:

~/.openclaw/workspace-covletter

So the most likely problem is:

your skill file exists in one workspace

#

but the covletter agent is actually using a different workspace

Check both paths side by side

openclaw --version
openclaw config get agents.list

ls -la ~/.openclaw/workspace-covletter
ls -la ~/.openclaw/workspace/covletter

find ~/.openclaw/workspace-covletter/skills -maxdepth 3 -type f 2>/dev/null | sort
find ~/.openclaw/workspace/covletter/skills -maxdepth 3 -type f 2>/dev/null | sort

What I expect you’ll see

#

Your SKILL.md is probably here:

~/.openclaw/workspace-covletter/skills/coverletter/SKILL.md

but the agent is actually running here:

~/.openclaw/workspace/covletter

Fix options

Option A, easiest

Move or copy your files into the workspace the agent is actually using.

#

Option B, cleaner

Change the agent config so covletter uses the workspace where your files already are.

That looks like:

openclaw config get agents.list

Find the index for covletter, then set its workspace, for example:

openclaw config set agents.list[INDEX].workspace "~/.openclaw/workspace-covletter"
openclaw gateway restart

Replace INDEX with the real array index.

#

Then do one more important thing

Skills are snapshotted per session, so after fixing the workspace, use a fresh session for the test:

openclaw agent --agent covletter --session-id covletter-test-$(date +%s) --message "What skills do you have available?"

Then test the real workflow:

openclaw agent --agent covletter --session-id covletter-run-$(date +%s) --message "Create a tailored cover letter for https://example.com/job/123 using CV1.pdf"

If it still fails after that

Then the next thing to check is whether covletter has a skill allowlist that excludes cover_letter.

#

So if needed, paste:

openclaw config get agents.list
sed -n '1,80p' ~/.openclaw/workspace-covletter/skills/coverletter/SKILL.md

I’m pretty confident this is a workspace-path mismatch though.

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

raw lily Apr 21, 2026, 11:40 AM

#

$ openclaw config get agents.list

🦞 OpenClaw 2026.4.15 (041266a) — Built by lobsters, for humans. Don't question the hierarchy.

[
{
"id": "main"
},
{
"id": "covletter",
"name": "covletter",
"workspace": ~/.openclaw/workspace/covletter",
"agentDir": "~/.openclaw/agents/covletter/agent"
}
]

so the command would be:
openclaw config set agents.list.main.workspace "~/.openclaw/workspace-covletter"
openclaw gateway restart

correct?

shrewd pendantBOT Apr 21, 2026, 11:40 AM

#

Close, but not quite.

You want to change the covletter entry, which is array index [1], not main.

Correct command

openclaw config set agents.list[1].workspace "~/.openclaw/workspace-covletter"
openclaw gateway restart

Not this

openclaw config set agents.list.main.workspace ...

That path is wrong for two reasons:

#

agents.list is an array, so you use [1], not .main
you want to update covletter, not the main agent

Then verify

openclaw config get agents.list

You want to see:

{
  "id": "covletter",
  "workspace": "~/.openclaw/workspace-covletter"
}

#

Then test with a fresh session

This part matters because skills are snapshotted per session:

openclaw agent --agent covletter --session-id covletter-test-$(date +%s) --message "What skills do you have available?"

Then the real test:

openclaw agent --agent covletter --session-id covletter-run-$(date +%s) --message "Create a tailored cover letter for https://example.com/job/123 using CV1.pdf"

So yes, same idea, but the exact fix is:

#

openclaw config set agents.list[1].workspace "~/.openclaw/workspace-covletter"
openclaw gateway restart

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

raw lily Apr 21, 2026, 11:47 AM

#

what is the usual standard location of new agent workspaces? In the root directory of openclaw or a subfolder of the workspace directory?

shrewd pendantBOT Apr 21, 2026, 11:48 AM

#

Usually, not in the repo root.

Normal default idea

OpenClaw workspaces usually live under the state dir:

~/.openclaw/

So the common pattern is:

main agent:
```
~/.openclaw/workspace
```
extra agents:

#

commonly something like

~/.openclaw/workspace-<agentId>

or, on some installs/flows, a per-agent subfolder such as

~/.openclaw/workspace/<agentId>

For your machine

The authoritative answer is whatever this shows:

openclaw config get agents.list

Right now, for your covletter agent, that is:

#

~/.openclaw/workspace/covletter

So for your current setup, the new agent workspace is a subfolder under the workspace directory, not the OpenClaw repo root.

Rule of thumb

Do not guess
use the path in agents.list[].workspace

So yes, conceptually:

not the OpenClaw source root
yes, typically somewhere under ~/.openclaw/

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

raw lily Apr 21, 2026, 11:50 AM

#

openclaw config get agents.list shows me this workspace:
"workspace": "/home/gloor/.openclaw/workspace-covletter",
"agentDir": "/home/gloor/.openclaw/agents/covletter/agent"

but:
$ openclaw agent --agent covletter --session-id covletter-test-$(date +%s) --message "What skills do you have available?"

gives me the error message:
Currently, within the /home/gloor/.openclaw/workspace/covletter directory,

so it looks like there is workspace mess (missmatch):
/home/gloor/.openclaw/workspace-covletter
/home/gloor/.openclaw/workspace/covletter

How do I ensure, the workspace is correctly registered?

shrewd pendantBOT Apr 21, 2026, 11:51 AM

#

Yep, this is the important distinction:

The config is authoritative

This is the real workspace registration:

openclaw config get agents.list

If that shows:

/home/gloor/.openclaw/workspace-covletter

then that is the workspace OpenClaw should use for covletter.

#

The agent’s plain-text reply is not authoritative

This part:

Currently, within the `/home/gloor/.openclaw/workspace/covletter` directory

is just model-generated text. It can be stale or simply wrong.

So do not trust the assistant’s narration for path verification.
Trust:

openclaw config get agents.list
actual tool output

#

Best way to prove the real runtime workspace

Use a fresh session and ask the agent to run pwd via exec:

openclaw agent --agent covletter --session-id covletter-pwd-$(date +%s) --message "Use exec to run pwd with no explicit workdir, then reply with only the output path."

Because exec defaults to the agent workspace, this is the clean test.

If it prints:

/home/gloor/.openclaw/workspace-covletter

then your workspace registration is correct, and the earlier path was just bogus model text.

#

If it prints:

/home/gloor/.openclaw/workspace/covletter

then the config change did not actually take effect.

I would run these 3 commands in order

openclaw config get agents.list
openclaw gateway restart
openclaw agent --agent covletter --session-id covletter-pwd-$(date +%s) --message "Use exec to run pwd with no explicit workdir, then reply with only the output path."

#

Also check whether both folders still exist

ls -la /home/gloor/.openclaw/workspace-covletter
ls -la /home/gloor/.openclaw/workspace/covletter

If both exist, that explains the confusion. Once you confirm the correct one, keep using only that one.

Short answer

To ensure the workspace is correctly registered:

#

set it in agents.list[].workspace
restart the gateway
verify with exec -> pwd, not with the model’s prose

If you want, next paste the output of that pwd test and I’ll tell you immediately whether the registration is actually fixed.

raw lily Apr 21, 2026, 11:57 AM

#

cd ~/.openclaw/workspace-covletter
openclaw skills list --eligible --verbose
openclaw skills info cover_letter

doesn't show my covletter

shrewd pendantBOT Apr 21, 2026, 11:57 AM

#

Yep, and that is actually expected here.

Two separate things are getting mixed together:

1. `covletter` is the agent id

It is not the skill name.

So openclaw skills list would never show covletter unless you literally named the skill that.

Your skill name is probably something like:

cover_letter

2. On your build, `openclaw skills list` / `openclaw skills info ...` are not a good check for a non-default agent

They resolve against the default agent workspace, not automatically the covletter agent just because you cd there.

#

So this:

cd ~/.openclaw/workspace-covletter
openclaw skills list --eligible --verbose
openclaw skills info cover_letter

is not a reliable test for the covletter agent.

Also, --eligible hides anything that is not currently eligible.

What to use instead

Use the targeted agent directly and make it prove its workspace/files via tools:

#

openclaw agent --agent covletter --session-id covletter-debug-$(date +%s) --message "Use exec to run pwd and then ls -R skills. Reply with the exact outputs."

That is much better than openclaw skills list for this case.

Why this works

pwd proves the real runtime workspace
ls -R skills proves whether the skill file is actually visible in that workspace

Short version

At this point:

do not use openclaw skills list as your main debug signal for covletter

#

do use openclaw agent --agent covletter ... with a fresh session id

If you paste the output of this one command:

openclaw agent --agent covletter --session-id covletter-debug-$(date +%s) --message "Use exec to run pwd and then ls -R skills. Reply with the exact outputs."

I can tell you immediately whether the workspace/skill registration is correct.

raw lily Apr 21, 2026, 12:08 PM

#

openclaw agent --agent covletter --message "What skills do you currently have available?"

result:
Currently, within the .openclaw/workspace-covletter directory, I don't have direct access to your specific skill set. To generate a cover letter effectively, I need information about your background and the job opportunity.

that's strange to me as the command below previously showed the skill is available:
openclaw agent --agent covletter --session-id covletter-test-$(date +%s) --message "What skills do you have available?"

shrewd pendantBOT Apr 21, 2026, 12:09 PM

#

Yep, that actually makes sense now.

What’s happening

These two commands do not behave the same:

Reuses the existing main session

openclaw agent --agent covletter --message "What skills do you currently have available?"

Forces a fresh session

openclaw agent --agent covletter --session-id covletter-test-$(date +%s) --message "What skills do you have available?"

And skills are snapshotted when a session starts.

#

So if you created or changed the skill after the old covletter main session already existed, then:

the old main session may not see the new skill
a fresh session will see it

So the good news

This strongly suggests your workspace registration is now fine.

The issue is probably just:

stale main session
fresh session sees updated skill snapshot

Practical rule while testing skills

#

Always use a fresh session id:

openclaw agent --agent covletter --session-id covletter-dev-$(date +%s) --message "Create a tailored cover letter for https://example.com/job/123 using CV1.pdf"

Do that every time you change:

SKILL.md
AGENTS.md
workspace files that affect startup context

Better than asking “what skills do you have?”

That question is a bit fuzzy and the model can answer loosely.

#

A better test is to ask it to do the actual workflow:

openclaw agent --agent covletter --session-id covletter-run-$(date +%s) --message "Create a tailored cover letter for https://example.com/job/123 using CV1.pdf"

Or a debug test:

openclaw agent --agent covletter --session-id covletter-debug-$(date +%s) --message "Use exec to run pwd and ls -R skills, then tell me the exact outputs."

Short answer

--agent covletter alone = probably reusing an old session

#

--session-id ... = fresh session, fresh skill snapshot
so for skill development, always use a new session id

I’m glad we caught that, it’s a subtle one.

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

raw lily Apr 21, 2026, 12:14 PM

#

i still miss the test to ensure the agent with skill is found an available

shrewd pendantBOT Apr 21, 2026, 12:15 PM

#

Yep, you want a real smoke test, not a vague question. Good call.

Best deterministic test

Add a tiny temporary rule to your SKILL.md.

1. Append this to `~/.openclaw/workspace-covletter/skills/coverletter/SKILL.md`

## Smoke test

If the user message is exactly:

skill-smoke-test

then reply with exactly:

#

COVLETTER_SKILL_LOADED

and nothing else.

2. Run a fresh session test

openclaw agent --agent covletter --session-id covletter-smoke-$(date +%s) --message "skill-smoke-test"

Expected result

If the skill is really loaded and available, the reply should be exactly:

#

COVLETTER_SKILL_LOADED

If it does not reply exactly that

then one of these is still wrong:

wrong workspace
stale session
skill file not parsed
skill not being loaded for that agent

Why this is the best test

Because this tests actual skill invocation behavior, not:

#

file existence only
model guessing
vague “what skills do you have?” wording

After the test works

Remove the smoke-test section again, or keep it for future debugging.

Then your real workflow test becomes:

openclaw agent --agent covletter --session-id covletter-run-$(date +%s) --message "Create a tailored cover letter for https://example.com/job/123 using CV1.pdf"

That’s the cleanest proof.

#

If you want, I can give you the final full SKILL.md with the smoke test already included.

raw lily Apr 21, 2026, 12:17 PM

#

: openclaw-gateway.service
$ openclaw agent --agent covletter --session-id covletter-smoke-$(date +%s) --message "skill-smoke-test"

🦞 OpenClaw 2026.4.15 (041266a) — Powered by open source, sustained by spite and good documentation.

It seems there was a misunderstanding. The skill-smoke-test command is not recognized as a valid function in the current workspace context.

Could you please provide more details about what you are trying to achieve? Are you looking for specific information, need help with a certain task, or do you want to proceed with creating a tailored cover letter?

If you have already provided the necessary details and I am still not able to fetch the LinkedIn job posting and your CV, could you share those specifics again?

shrewd pendantBOT Apr 21, 2026, 12:18 PM

#

Good, this tells us something useful.

That result does not prove the skill is missing.
It only proves the model did not auto-trigger your smoke-test rule from plain text.

That can happen even when the skill exists.

Better test: invoke the skill directly

Use the generic skill command:

openclaw agent --agent covletter --session-id covletter-smoke-$(date +%s) --message "/skill cover_letter skill-smoke-test"

Replace cover_letter if your actual name: in SKILL.md is different.

#

What the outcomes mean

If it works

Then the skill is loaded and available, and the issue is only auto-triggering.

If you get something like:

Skill "cover_letter" not found

then the skill is not loaded for that agent/session.

Why this test is better

Plain message:

#

skill-smoke-test

still depends on the model deciding “this matches the skill”.

But:

/skill cover_letter ...

is an explicit skill invocation.

That is the real yes/no test.

#

One more thing to verify

Please check the top of SKILL.md and make sure the skill name is exactly what you invoke:

---
name: cover_letter
description: ...
---

If the name: is coverletter, then the command must be:

openclaw agent --agent covletter --session-id covletter-smoke-$(date +%s) --message "/skill coverletter skill-smoke-test"

#

So the next exact test is

openclaw agent --agent covletter --session-id covletter-smoke-$(date +%s) --message "/skill cover_letter skill-smoke-test"

Paste that result, and we’ll know immediately whether the skill is actually loaded or just not being auto-picked.

raw lily Apr 21, 2026, 12:24 PM

#

let's start over again, I am more confused with every answer:

'openclaw agents list --bindings' gives me the relevant informatoin about the workspac and the covleter agent:

covletter
Workspace: ~/.openclaw/workspace-covletter
Agent dir: ~/.openclaw/agents/covletter/agent
Model: ollama/qwen2.5:3b
Routing rules: 0

why the hell is openclaw not finding the agent when I invoke it?

shrewd pendantBOT Apr 21, 2026, 12:25 PM

#

You’re right to reset here. The short answer is:

OpenClaw is finding the agent

If this works at all:

openclaw agent --agent covletter --message "..."

then the covletter agent was found.
--agent covletter bypasses routing, so Routing rules: 0 is irrelevant for this CLI test.

So the problem is not agent lookup.

What is probably failing instead

#

You showed this:

Model: ollama/qwen2.5:3b

That is the bigger red flag.

Small local Ollama models are often bad at:

following skills reliably
choosing tools
behaving consistently in agent workflows

So what you are seeing is much more likely:

agent found ✅

#

workspace found ✅
weak model not following the skill/tool flow reliably ❌

Let’s simplify the test

Ignore openclaw skills list for now.
Ignore “what skills do you have?” questions too.

Use the one test that matters:

openclaw agent --agent covletter --session-id covletter-test-$(date +%s) --message "/skill cover_letter skill-smoke-test"

Interpretation

#

If it says:

Skill "cover_letter" not found

Then the skill is not loaded.

If it runs the skill

Then the agent/workspace are fine, and your real issue is model quality / auto-trigger behavior.

Important distinction

There are two different problems:

Agent not found
That is not your problem.

#

Agent found, but behaving dumb/inconsistently
That is likely your problem.

And with ollama/qwen2.5:3b, I’m honestly not surprised.

My recommendation

For this workflow, do not debug it first on a tiny local model.

First get it working with a tool-reliable model.
After that, if you want, try moving back to Ollama.

Model docs: https://docs.openclaw.ai/concepts/models
Fresh community model advice: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

#

One clean next step

Run exactly this:

openclaw agent --agent covletter --session-id covletter-test-$(date +%s) --message "/skill cover_letter skill-smoke-test"

and paste the output.

That will tell us, cleanly, whether:

the skill is loaded, or
it really is missing.

#

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

raw lily Apr 21, 2026, 12:31 PM

#

$ openclaw agent --agent covletter --session-id covletter-test-$(date +%s) --message "/skill cover_letter skill-smoke-test"

🦞 OpenClaw 2026.4.15 (041266a) — Ah, the fruit tree company! 🍎

│
◇
The command /skill cover_letter skill-smoke-test is not recognized in this workspace.

shrewd pendantBOT Apr 21, 2026, 12:33 PM

#

I’m going to check one more thing in the docs/source, because that exact /skill ... not recognized in this workspace wording matters.

#

Yeah, this is frustrating. I think the clean reset is:

OpenClaw is finding the agent

If this command returns a reply at all:

openclaw agent --agent covletter --message "..."

then covletter was found and used.

So the problem is not “agent lookup”.

What is actually going wrong

#

You have:

Model: ollama/qwen2.5:3b

At this point, that is the main problem.

What I think is happening:

OpenClaw finds covletter correctly ✅
the message gets to that agent ✅
the small Ollama model treats /skill ... like plain text or answers loosely ❌

So when you see:

#

The command `/skill cover_letter skill-smoke-test` is not recognized in this workspace.

that is very likely the model talking, not a reliable gateway diagnostic.

So let’s stop blaming agent registration

Your agent registration looks fine:

openclaw agents list --bindings shows covletter
workspace path is there
openclaw agent --agent covletter ... returns a response

That means the agent is there.

#

My honest recommendation

For this workflow, stop testing on ollama/qwen2.5:3b.

It is too weak for reliable:

skill following
tool use
command interpretation
workflow automation

First get the cover-letter flow working with a tool-reliable model.
Then, if you want, try downgrading later.

Docs: https://docs.openclaw.ai/concepts/models

#

Fresh community advice: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

Two reliable next options

Option 1, recommended

Temporarily switch covletter to the same stronger model you already know works elsewhere, then re-run your smoke test.

Option 2

Test the skill from a chat surface with real slash commands, for example Discord or WebChat, instead of through this CLI path.

Short version

You are not fighting agent registration anymore.

#

You are fighting a small local model that is bad at agent workflows.

That’s why this feels inconsistent.

If you want, I can help you with the next exact step to switch covletter to a stronger model for testing, or help you run the smoke test from Discord/WebChat instead.

raw lily Apr 21, 2026, 12:36 PM

#

$ ollama list
NAME ID SIZE MODIFIED
qwen3.5:latest 6488c96fa5fa 6.6 GB 31 hours ago
qwen3.5:2b 324d162be6ca 2.7 GB 2 days ago
llama3.2:3b a80c4f17acd5 2.0 GB 2 days ago
llama3.2:1b baf6a787fdff 1.3 GB 2 days ago
qwen2.5:7b 845dbda0ea48 4.7 GB 5 days ago
qwen2.5:3b 357c53fb659c 1.9 GB 6 days ago

would qwen2.5:7b be better or shall I try qwen3.5:2b or qwen3.5:latest?

shrewd pendantBOT Apr 21, 2026, 12:37 PM

#

I’m checking the exact config path before I tell you the switch command, so I don’t hand you a fake key.

#

For this exact debugging task, yes, go bigger, not smaller.

My practical recommendation from the ones you already have

Try in this order:

qwen3.5:latest
qwen2.5:7b
only if you’re desperate, the smaller ones

I would not spend time on:

qwen3.5:2b
llama3.2:3b
llama3.2:1b

for skill/tool debugging. They’re too small for this kind of agent workflow.

#

Why

Your issue right now is not “raw text generation”.
It is:

skill following
tool use
command interpretation
workflow consistency

For that, larger local models are usually less bad than 2B/3B-class ones.

So yes, first try

openclaw config set agents.list[1].model "ollama/qwen3.5:latest"

#

openclaw gateway restart

Then test with a fresh session:

openclaw agent --agent covletter --session-id covletter-test-$(date +%s) --message "Create a tailored cover letter for https://example.com/job/123 using CV1.pdf"

If that still feels flaky

Try:

openclaw config set agents.list[1].model "ollama/qwen2.5:7b"
openclaw gateway restart

#

and repeat the same fresh-session test.

Honest expectation

Even the better local option may still be annoying for agent workflows.

So my real advice is:

use the best local model you have only to prove the wiring
if it still behaves inconsistently, switch to a tool-reliable cloud model just for building/debugging the workflow

Docs: https://docs.openclaw.ai/concepts/models
Fresh community notes: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

If you want, after you try qwen3.5:latest, paste the result and I’ll help you decide whether to keep pushing local or stop wasting time and switch to cloud for setup.

inner flowerBOT Apr 21, 2026, 12:53 PM

#

raw lily Apr 21, 2026, 12:55 PM

#

last question before I close the thread, how much VRAM do I need to locally run a 100b modell fast enough to get e.g. 20 tps output?

shrewd pendantBOT Apr 21, 2026, 12:55 PM

#

Very rough rule of thumb, not a promise:

For a ~100B local model

weights alone
- 4-bit: roughly 50 to 70 GB VRAM
- 8-bit: roughly 100+ GB VRAM
practical serving headroom (KV cache, context, runtime overhead)
- more like 80 to 120 GB+
to get something like ~20 tok/s reliably
- think datacenter-class multi-GPU territory, not “one normal gaming GPU”

Short answer

If your goal is 100B + ~20 tok/s, I would mentally budget more like:

at least ~120 GB aggregate VRAM
and realistically often 160 GB+ with fast interconnect

#

Reality check

For OpenClaw-style agent work, local 100B at that speed is usually in the:

very expensive
multi-GPU
not worth it for most people

bucket.

So yeah, this is why I kept pushing back on tiny local models and also why I wouldn’t recommend “just run a huge one locally” as the normal path.

Docs: https://docs.openclaw.ai/concepts/models
Fresh hardware/model chatter: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

And honestly, for fresh hands-on hardware advice, I’d ask in #models. That changes fast.

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

raw lily Apr 21, 2026, 12:56 PM

#

ok, what gpu with how much VRAM for a 70b model?

shrewd pendantBOT Apr 21, 2026, 12:57 PM

#

Rough rule of thumb:

For a 70B local model

4-bit weights: about 35 to 45 GB
practical headroom (KV cache, runtime, context): more like 48 to 80 GB

So hardware-wise

1x 48 GB GPU: bare minimum-ish, still tight
1x 80 GB GPU: much more realistic
2x 24 GB GPUs: possible for some setups, but usually more annoying/slower
2x 48 GB: comfortable

Short answer

If you want a sane experience with a 70B model, I’d think in terms of:

48 GB minimum
80 GB preferred

#

And for OpenClaw-style agent use, I’d lean toward 80 GB class hardware if you want less pain.

As always, exact reality depends on:

quantization
context length
backend
dense vs MoE
target tok/s

For fresh hands-on hardware recs, I’d still ask in #models. That moves fast.

#Agent questions

0. First, verify your OpenClaw install

1. Create or inspect the dedicated agent

2. Important: model auth is per agent

3. Put your files into the agent workspace

4. Change one thing in your design

5. Add agent-specific instructions in AGENTS.md

6. Create the custom skill

If your build script uses something else

7. Make sure build.ksh is agent-friendly

8. Reload the skill

9. Test it from the terminal first

Test 1, simple availability

Test 2, missing inputs

Test 3, full run

Test 4, refinement

10. How to use it in chat / TUI

11. Recommended v1 behavior

12. Recommended v2 improvements

A. Add a plain text profile file

B. Keep multiple templates

C. Store outputs per run

D. Add Discord routing later

13. Best order to build this

14. The shortest possible working command set

Best option, recommended

What to add to SKILL.md

If you want a separate prompt file anyway

My recommendation

First, please run this

Then run these instead

Also verify the file is really where OpenClaw expects it

Most likely causes

Known-good frontmatter

So, most likely: your skill is fine, you’re just inspecting the wrong workspace

Best checks right now

1. Verify the skill file exists

2. Test the target agent directly

3. Also try a direct trigger

Important takeaway

If you want, I’d do this next

Check both paths side by side

What I expect you’ll see

Fix options

Option A, easiest

Option B, cleaner

Then do one more important thing

If it still fails after that

Correct command

Not this

Then verify

Then test with a fresh session

Normal default idea

For your machine

Rule of thumb

The config is authoritative

The agent’s plain-text reply is not authoritative

Best way to prove the real runtime workspace

If it prints:

If it prints:

I would run these 3 commands in order

Also check whether both folders still exist

Short answer

1. covletter is the agent id

2. On your build, openclaw skills list / openclaw skills info ... are not a good check for a non-default agent

What to use instead

Why this works

Short version

What’s happening

Reuses the existing main session

Forces a fresh session

So the good news

Practical rule while testing skills

Better than asking “what skills do you have?”

Short answer

Best deterministic test

1. Append this to ~/.openclaw/workspace-covletter/skills/coverletter/SKILL.md

2. Run a fresh session test

Expected result

If it does not reply exactly that

5. Add agent-specific instructions in `AGENTS.md`

7. Make sure `build.ksh` is agent-friendly

What to add to `SKILL.md`

1. `covletter` is the agent id

2. On your build, `openclaw skills list` / `openclaw skills info ...` are not a good check for a non-default agent

1. Append this to `~/.openclaw/workspace-covletter/skills/coverletter/SKILL.md`