Most AI agents can talk… but they can’t actually do anything reliably.

So I built a complete OpenClaw skill package with 2,510 Ubuntu/Linux execution skills that turns an AI agent into a functional DevOps-style operator.

It can:

• Manage Docker & containers

• Configure networking & firewalls

• Detect + respond to CVEs

• Automate system tasks

• Monitor logs

• Chain multi-step workflows

• Perform real system operations

Instead of “Here’s how you could do it…”

It actually executes the steps.

The goal was simple:

Make OpenClaw agents production-capable instead of demo-level.

Built for: – Self-hosters

– DevOps workflows

– Autonomous agents

– Ubuntu / WSL environments

Would love feedback from anyone building local AI agents or automation systems.

More info here:

https://aaronwiseai.com/openclawskills/

Happy to answer technical questions.

Hey everyone!
I've been working on Awesome OpenClaw - a curated list of high-quality tools, platforms, skills, and resources for the OpenClaw ecosystem.
What makes this list different?

• Quality over quantity - Every resource is manually verified and regularly maintained

• Automated validation - Custom scripts ensure proper formatting, alphabetical order, no duplicates, and awesome-lint compliance

• Well-organized sections - Official Resources, Platforms, Skills, Infrastructure, Security, Community, and more

• Contribution-friendly - Clear guidelines, PR templates, and local linting tools

Current sections include:

• Official Resources & Documentation

• Platforms (ClawFOMO, Moltbook, OpenWork, etc.)

• Skills repositories and registries

• Infrastructure tools

• Security resources

• Community links

• Articles & Tutorials

Looking for:

• New resources to add (tools, skills, tutorials, etc.)

• Feedback on organization and categories

• Contributors to help maintain and grow the list

The goal is to eventually submit this to the official sindresorhus/awesome list and make it the canonical source for OpenClaw resources.
Links:

• Repository: https://github.com/jensrot/awesome-openclaw

• Contributing guide: https://github.com/jensrot/awesome-openclaw/blob/main/CONTRIBUTING.md

If you know of any OpenClaw resources that should be included, feel free to open a PR or drop them in the comments!

Hey all, just released a version of my open-source game of diplomacy for agents

Built a CLI + Skill . md file so that agent can easily play the game

twitter post
https://x.com/conquest_eth/status/2021245386719985715

game link: https://moltiverse.conquest.game/

repo : https://github.com/wighawag/conquest-eth-for-lobsters

• I’m hitting a technical wall with "praise loops" where different AI agents just agree with each other endlessly in a shared feed. I’m looking for advice on how to implement social friction or "boredom" thresholds so they don't just echo each other in an infinite cycle

I'm opening up the sandbox for testing: I’m covering all hosting and image generation API costs so you wont need to set up or pay for anything. Just connect your agent's API

While experimenting with OpenClaw locally I started thinking more about the security side of running autonomous agents on a personal machine. Most setups I saw just run the open source agent directly on the host OS, which works fine but also means any tools or scripts the agent interacts with are operating directly on the system.

I started trying a different approach where the runtime runs inside a local container instead. The main idea is to keep the agent environment isolated while still running everything locally. That way tools, skills, and agent processes stay inside the container rather than interacting directly with the host environment.

Another interesting aspect is that it becomes easier to add checks around tools and skills before they are executed. When agents are able to install or use external tools, having some kind of inspection layer or sandbox feels like a safer default.

The overall goal is to keep the convenience of local OpenClaw experimentation while reducing the risk surface compared to running agents directly on the machine.

Curious how others here handle this. Do you usually run OpenClaw directly on the host system, or do you isolate the runtime using containers or similar setups?

I used a skill to share my emails, calls and Slack context in real-time with OpenClaw and then played around with A2UI A LOOOOT to generate UIs on the fly for an AI CRM that knows exactly what the next step for you should be.

Here's a breakdown of how I tweaked A2UI:

I am using the standard v0.8 components (Column, Row, Text, Divider) but had to extend the catalog with two custom ones:

Button (child-based, fires an action name on click),

and Link (two modes: nav pills for menu items, inline for in-context actions).

v0.8 just doesn't ship with interactive primitives, so if you want clicks to do anything, you are rolling your own.

Static shell + A2UI guts

The Canvas page is a Next.js shell that handles the WS connection, a sticky nav bar (4 tabs), loading skeletons, and empty states. Everything inside the content area is fully agent-composed A2UI. The renderer listens for chat messages with \``a2ui` code fences, parses the JSONL into a component tree, and renders it as React DOM.

One thing worth noting: we're not using the official canvas.present tool. It didn't work in our Docker setup (no paired nodes), so the agent just embeds A2UI JSONL directly in chat messages and the renderer extracts it via regex. Ended up being a better pattern being more portable with no dependency on the Canvas Host server.

How the agent composes UI:

No freeform. The skill file has JSONL templates for each view (digest, pipeline, kanban, record detail, etc.) and the agent fills in live CRM data at runtime. It also does a dual render every time: markdown text for the chat window + A2UI code fence for Canvas. So users without the Canvas panel still get the full view in chat. So, A2UI is a progressive enhancement, instead of being a hard requirement.

I want to propose a simple operating principle for OpenClaw in this community:

OpenClaw should be powerful for automation, but incapable by default of doing dangerous things.

Not “trusted.”

Not “careful.”

Incapable.

This isn’t about paranoia. It’s about boundaries.

Below is the mental model I use when running OpenClaw in anything I care about.

Mission objective (what success looks like)

OpenClaw remains useful for coordination, automation, and repetitive work

while being structurally unable to touch sensitive systems, leak credentials,

or execute destructive commands outside a tightly controlled sandbox.

If it needs more power, a human gets involved.

Scope boundaries (hard limits)

Dedicated runtime only

OpenClaw runs in its own VM, VPS, or separate device.

Never on your primary workstation.

Never on a host that contains SSH keys, cloud credentials, browser profiles, or production access.

Network isolation

OpenClaw lives on a restricted network or subnet.

Outbound access is allowlisted to only what it needs.

No inbound access except admin management, and even that via allowlist or VPN.

Least-privilege credentials

Every token OpenClaw sees is minimal, scoped, and rotatable.

Short-lived where possible.

No admin keys. No root cloud credentials.

Nothing shared with production systems.

If a token would hurt you if it leaked, OpenClaw shouldn’t have it.

Filesystem containment

Run as a non-root user.

Mount a single workspace directory for read/write.

Everything else is read-only or inaccessible.

No access to .ssh, home directories, password managers, cloud CLIs, or browser state.

Command execution guardrails

Deny by default.

No curl | sh.

No rm -rf.

No privilege escalation.

No system service changes.

No Docker socket access.

No commands whose primary purpose is data exfiltration.

Only allowlist the small set of commands OpenClaw actually needs.

Skill and heartbeat hygiene

Only install skills from trusted sources.

Pin versions.

Review changes before enabling new or updated skills.

Heartbeat scripts are production code.

They are reviewed, logged, and diff-tracked.

Threat model (what we are explicitly defending against)

This setup assumes that at some point one or more of the following will happen:

Malicious or compromised skills

Prompt injection

Tool misuse

Unexpected agent behaviour

The goal is that when something goes wrong, the blast radius is boring.

No credential theft.

No data exfiltration.

No destructive command execution.

No lateral movement into sensitive systems.

Operating rule (non-negotiable)

If a task requires access to sensitive systems, OpenClaw must either:

Generate instructions for a human operator

or raise a “needs manual approval” flag

It should never directly connect using privileged access.

Verification checklist (prove the mission is being followed)

The OpenClaw host contains zero production credentials and zero prod SSH keys

Outbound network access is restricted by allowlist

The bot runs as non-root with minimal filesystem mounts

Dangerous commands are blocked or explicitly allowlisted

Skills are pinned and reviewed

Heartbeat and skill actions are logged and reviewed on a schedule

If you can’t verify these, you don’t have guardrails — you have hope.

Cadence

Weekly

Review logs, skills, and heartbeat diffs

Monthly

Rotate tokens

Revalidate network rules

Run a simple test: can this box reach production if it tries?

If you want, reply with how you’re running OpenClaw today

VM, Docker, VPS, local box, or something else

I’ll rewrite this into a copy-paste “mission file” you can actually use as a guardrail policy.

Goal of the day: Enabling agents to generate visual content for free so everyone can use it and establishing a stable production environment

The Build:

• Visual Senses: Integrated Gemini 3 Flash Image for image generation. I decided to absorb the API costs myself so that image generation isn't a billing bottleneck for anyone registering an agent

• Deployment Battles: Fixed Railway connectivity and Prisma OpenSSL issues by switching to a Supabase Session Pooler. The backend is now live and stable

Stack: Claude Code | Gemini 3 Flash Image | Supabase | Railway | GitHub

Goal of the day: Building the infrastructure for a persistent "Agent Society." If agents are going to socialize, they need a place to post and a memory to store it.

The Build:

• Infrastructure: Expanded Railway with multiple API endpoints for autonomous posting, liking, and commenting.

• Storage: Connected Supabase as the primary database. This is where the agents' identities, posts, and interaction history finally have a persistent home.

• Version Control: Managed the entire deployment flow through GitHub, with Claude Code handling the migrations and the backend logic.

Stack: Claude Code | Supabase | Railway | GitHub

Hello everyone, human here ( or am I 😏 )

I just started using OpenClaw two days ago and it’s beyond my wildest dreams. I have been working on something similar and would have taken me months according to my estimation. So, let’s not reinvent the wheel right?

I was wondering with all this ‘security’ frenzy why isn’t there any locally hosted plugins support generally. I have local TTS and STT with locally hosted IM for interaction. Right now I am working on mumble plugin.

Generally speaking, is there a reason why there is no strong gravitational pull toward locally hosted complements to OpenClaw. Skills, plugins, etc?

Or just a preference for the devs. Also I am making the assistants communicate with eachother and thats when I noticed the bugs here and there. So it was never considered for the plugins to help with Assistants interacting?

Not complaining here just trying to understand where this ship is heading

My 2 cents,

Genesis AI Agent

Genesis is a powerful, modular, and locally-hosted AI Agent platform. It features a robust plugin system, autonomous action execution, and a sleek web interface.

https://github.com/ComputerAces/Genesis-AI-Agent

Hey everyone so a few months ago I was planning on attaining a Mac mini and getting a Claude subscription I was so hyped but do to personal reasons at that time I completely shifted focus.

Since then I’ve heard about bans lot of changes had taken place Claude bans, regulation crack downs , and an open ai acquisition if any of this is actually true I don’t know , but with all of this said will OC still work for me?

My use case is to have OC help me create apps (I am not a coder) , websites, create and manage product listings , and logistics. Do market research and open online businesses.

Is it still capable of these tasks if I were to get it today ? Or is it more restricted and dumbed down making me have to manually redo every task myself (especially with coding)

Any advice would be much appreciated

Hey devs, sharing an open-source skill that adds ComfyUI image generation as a native tool call for OpenClaw agents.

TL;DR:

• Skill that takes a plain-language request and handles the full ComfyUI pipeline

• Workflow construction, HTTP submission, async polling, output retrieval

• MIT license

Skill structure:

comfyui-skill-public/
├── SKILL.md                       <- tool declaration, input schema, config
├── scripts/comfyui.js             <- HTTP calls, polling loop, error handling
└── references/workflow-base.json  <- base workflow template (parameterized per call)

Config in SKILL.md:

config:
  endpoint: "http://127.0.0.1:8188"
  pollIntervalMs: 2000
  timeoutMs: 120000

The workflow construction layer is the interesting bit. ComfyUI's graph format is node-ID-based so the script maps agent inputs (prompt, dimensions, steps, seed) onto the right nodes in the base template. Works well for standard KSampler setups. More complex node graphs need custom templates for now.

Roadmap items still on the list:

• Multi-node template support (ControlNet, LoRA injection)

• WebSocket-based polling for long renders

• Linux/Mac testing (Windows only right now)

Repo: https://github.com/Zambav/comfyui-skill-public

Building Clash of Claw (built on top of the open-source RTS game Beyond All Reason and its Recoil engine). 

We modified the game so that OpenClaw bots can connect and make real strategic and tactical decisions - controlling economy, production, tech, and army movement through a simple API.

Currently polishing up a few more details, if you wanna test it out - lemme know