Add OpenClaw support (skill + before_tool_call boundary plugin)

[nabsha]

Goal

Ship kdbx for OpenClaw (open-source self-hosted agent framework) in addition to Claude Code. OpenClaw uses the same AgentSkills SKILL.md standard, so the skill ports almost as-is; the enforced agent/human boundary is the only real work.

What ports vs. what changes

Piece	OpenClaw target	Effort
SKILL.md	same file + an OpenClaw gating block; swap hardcoded paths for {baseDir}	light
kdbx.py (PEP-723) + kdbx_core/	bundled scripts/, run via the exec tool	none (uv/lockfile are the skill's own concern)
/kdbx:* commands	a skill is a slash command by default (user-invocable: true)	light
MCP server	openclaw mcp add … (native MCP client)	light
PreToolUse leak/role guard (guard.py)	a separate OpenClaw TypeScript plugin with a before_tool_call hook	🔴 rewrite

Plan

1. Skill frontmatter (cheap, high value). Add to skills/kdbx/SKILL.md (Claude Code ignores unknown fields, so one file serves both):

   metadata:
     openclaw:
       requires: { bins: ["uv", "keepassxc-cli"] }   # auto-disable if prereqs missing

   Body: instruct exec to run uv run --locked {baseDir}/scripts/kdbx.py <op> with host: "gateway" (kdbx needs host FS ~/.config/keepassxc, not the Docker sandbox).
2. Boundary plugin (the real work). Port plugins/kdbx/hooks/guard.py → a TS plugin registering before_tool_call:
   • { block: true, blockReason } for agent-issued kdbx set/delete/mv/import/rekey/export + get --reveal/--clip (terminal block, parity with a Claude Code deny).
   • { requireApproval: {...} } for delete --purge / rekey (replaces the TTY confirm).
   • Bonus: resolve_exec_env can inject secrets into the exec env (agent never sees them in args); tool_result_persist can scrub leaked values from transcripts.
3. Distribute via ClawHub ("Skill + Plugin Registry") as a plugin bundle (skill + boundary plugin grouped), and openclaw skills install.

Keep shared, don't fork

kdbx.py / kdbx_core stay the single source of truth; OpenClaw gets a parallel packaging target alongside the Claude Code plugin (mirrors the symlink/dereference approach).

Open verification (smoke-test against a real install first)

npm i -g openclaw && openclaw skills install ./skills/kdbx to confirm, before publishing:

• exact before_tool_call return shape (still evolving — Feature Request: Pre-tool hooks (gate scripts that block tool execution) openclaw/openclaw#14159)
• whether requires.config can point at a repo file like .keepassxc.json or only OpenClaw config keys
• sandbox-off / host: gateway reaches the host keychain + ~/.config/keepassxc

Sources

docs.openclaw.ai/tools/{skills,creating-skills,exec} · docs.openclaw.ai/plugins/hooks · docs.openclaw.ai/clawhub · github.com/openclaw/agent-skills (real SKILL.md) · github.com/openclaw/openclaw#14159

Relates to #4 (cross-ecosystem discoverability). Not started — research + plan only.

[caioribeiroclw-pixel]

I did a quick OpenClaw smoke against the current main (28382bf) in an isolated HOME/agent so it would not touch my real workspace.

Environment:

• OpenClaw 2026.6.6 (8c802aa)
• isolated HOME=/tmp/yarrasys-skills-openclaw-validation/home
• agent id: yarrasys-validation

What worked:

openclaw skills install ./skills/kdbx --agent yarrasys-validation --as kdbx

Result:

Installing to /tmp/yarrasys-skills-openclaw-validation/home/.openclaw/workspace-yarrasys-validation/skills/kdbx…
Installed kdbx from path -> /tmp/yarrasys-skills-openclaw-validation/home/.openclaw/workspace-yarrasys-validation/skills/kdbx

openclaw skills info kdbx --agent yarrasys-validation then reported:

kdbx ✓ Ready
Source: openclaw-workspace
Visible to model: yes
Available as command: yes

The important catch: this host has neither uv nor keepassxc-cli installed, but OpenClaw still marked the skill as ready because the current SKILL.md has no OpenClaw-readable requirements gate yet.

uv path: MISSING
keepassxc-cli path: MISSING
uv run --locked .../kdbx.py --help -> exit 127
/bin/bash: uv: command not found

So the first OpenClaw port looks like it should start with the metadata/readiness side before the TS boundary plugin:

1. add an OpenClaw requirements block for uv + keepassxc-cli (or whatever the current skills schema expects),
2. keep the command example rooted at the installed skill dir / {baseDir} rather than repo-relative paths,
3. only after that, port the Claude PreToolUse guard into before_tool_call / approval hooks.

This is actually a useful failure mode: install/discovery works today, but readiness is a false positive without dependency gating. That is the first receipt I would want before testing secret boundaries.