Forem: Rost

OpenClaw Rise and Fall — Timeline and Real Reasons Behind the Collapse

Rost — Tue, 28 Apr 2026 12:50:44 +0000

OpenClaw did not fail as a product. It lost its fuel.

What looks like a dramatic boom and collapse is actually something more mechanical and more interesting. OpenClaw was a thin layer on top of a temporary economic advantage in the AI ecosystem. Once that advantage disappeared, so did the attention.

This article breaks down the exact timeline, the real drivers behind the spike, and why the drop was inevitable.

The illusion of product-driven growth

Most people assume OpenClaw grew because it was a great AI agent — and that is only partially true.

OpenClaw was genuinely useful. It supported more than 50 integrations, worked across Claude, GPT-4o, Gemini, and DeepSeek, and attracted enterprise adoption — Tencent built a platform directly on top of it. But capability alone did not set it apart from comparable alternatives:

Cline
LangChain-based setups
Other agent wrappers

The real driver was access rather than capability — a distinction that explains the entire arc of OpenClaw's rise and collapse.

OpenClaw made powerful models cheap to use at scale.

Phase 1. Quiet emergence (November 2025)

The story begins in November 2025, when Peter Steinberger built the first prototype in roughly one hour. He was annoyed that the tool did not exist yet, so he built it, calling it Clawdbot — a nod to Anthropic's Claude, complete with a lobster mascot.

The first version was practical rather than flashy: an AI agent that could manage calendars, check email, book appointments, and automate computer tasks on the user's behalf. Steinberger shared it in developer communities and early adopters recognized something promising, though growth at this stage remained slow and organic with no visibility outside technical circles.

Phase 2. The viral ignition (January–February 2026)

The spike began when several forces aligned in quick succession.

1. Naming drama and forced rebrands

In late January 2026, Anthropic sent Steinberger a trademark notice over "Clawdbot," citing phonetic similarity to "Claude." By his account, Anthropic handled it professionally — but the notice forced a rename. The project became Moltbot for three days, then OpenClaw, and the forced rebranding generated exactly the kind of attention that marketing budgets cannot buy.

2. The agent hype wave

The market was already primed for an agent breakthrough:

autonomous agents were trending across social media and the tech press
"AI that can act" had become the dominant narrative
developers were actively searching for tools that could automate complex workflows

OpenClaw arrived at exactly the right moment, when demand for this kind of tool was at its highest and the story of autonomous AI agents was capturing mainstream attention.

3. The cheap compute loophole

The most decisive factor was a compute pricing loophole that no amount of good engineering could have manufactured deliberately.

Users discovered that OpenClaw could connect to Claude by grabbing the OAuth token from a Claude Pro or Max subscription and spoofing the authentication headers of Anthropic's own Claude Code client. Instead of paying per token through the API, they effectively got:

near unlimited agent execution for a fixed monthly cost

The numbers made this explosive. A Claude Max subscription cost $200 per month, while running equivalent workloads through the API would cost far more — industry analysts estimated a price gap of more than five times, meaning Anthropic was quietly subsidising each heavy OpenClaw user by hundreds of dollars a month.

This changed behavior instantly:

developers ran heavy experiments they would never have attempted at API prices
viral demos flooded social media
large-scale automation became accessible to solo developers

Nothing in the software changed — the economics did, and that shift alone was enough to ignite a viral adoption curve. By March 2, 2026, the OpenClaw repository had accumulated 247,000 GitHub stars and 47,700 forks, reaching 100,000 stars in under 48 hours — a pace widely described as the fastest-growing GitHub project in history.

Phase 3. Peak usage and inflated expectations

At peak interest, developers pushed agents to extremes, social media amplified the results, and expectations exploded around what personal AI automation could achieve. An estimated 135,000 OpenClaw instances were running simultaneously when Anthropic made its announcement, and one founder described publicly how she had deployed nine separate AI agents to manage her administrative work and personal household logistics.

Why do AI tools suddenly become popular and then fade

Because the initial spike is driven by novelty and perceived leverage. Once users test the limits, reality sets in — the tool proves harder to use reliably, and the economic conditions that made it attractive often turn out to be temporary. In OpenClaw's case, the perceived leverage was real but built on borrowed economics that Anthropic had not priced for agentic workloads.

The creator leaves for OpenAI (February 2026)

Before the collapse arrived, OpenClaw lost its original architect.

On February 14–15, 2026, Steinberger announced he was leaving the project to join OpenAI. Sam Altman posted that Steinberger would "drive the next generation of personal agents" at the company, and Steinberger wrote that "teaming up with OpenAI is the fastest way to bring this to everyone." OpenClaw was transferred to an independent open-source foundation with OpenAI's continued support.

The timing was striking. Anthropic had declined to hire or partner with Steinberger, despite the fact that his tool had become arguably their best free marketing in years — a project built explicitly to showcase how good Claude was. Instead, he went directly to their biggest competitor, taking with him both the project's momentum and its community relationships.

Phase 4. The correction begins

Two things started happening at the same time.

1. Reality of agent limitations

Users who had deployed OpenClaw at scale began encountering its real constraints:

agents are brittle and fail unpredictably on multi-step tasks
reliability is inconsistent across different workflows and environments
setup and maintenance is non-trivial for most users outside technical circles

These limitations alone would have caused a gradual decline, but OpenClaw did not taper off gradually — it dropped sharply, because a second and more decisive force hit at exactly the same time.

2. The economic layer breaks

Anthropic had already run this playbook once. In January 2026, just weeks before OpenClaw peaked, they blocked OpenCode — another popular third-party coding client — from using Claude subscription tokens in what was framed as a terms of service violation, not a capacity issue. OpenClaw users had every reason to expect the same treatment, and that moment arrived in April.

Anthropic then introduced restrictions that closed the loophole entirely:

third-party tools were blocked from using subscription OAuth tokens
usage shifted to pay-as-you-go extra billing or full API keys

This removed the key advantage:

cheap large-scale execution

Now users faced a very different cost structure:

Metric	Before cutoff	After cutoff
Monthly plan cost	$20–$200 (flat)	$20–$200 + usage
Cost per task	Effectively $0	$0.50–$2.00
API rate (Sonnet 4.6 input)	Covered by sub	$3 per million tokens
API rate (Sonnet 4.6 output)	Covered by sub	$15 per million tokens
Increase for heavy users	—	10× to 50×

What caused the sudden drop in interest in AI agent tools

The answer is straightforward: not a lack of innovation, but the loss of affordable compute. Once the pricing floor disappeared, the incentive to experiment and share disappeared with it, and search interest followed almost immediately.

April 4, 2026 — The hard cutoff

On April 4, 2026, at 12 PM Pacific Time, the subscription access ended for all third-party tools.

Boris Cherny, Head of Claude Code at Anthropic, posted on X that Claude Pro and Max subscriptions would no longer cover usage from third-party tools, effective immediately. An Anthropic spokesperson confirmed that using subscriptions with third-party tools was always against the terms of service, and that those tools were placing "an outsized strain on our systems." Additional context made the timing feel urgent: on April 1, the full source code of Claude Code — 512,000 lines of TypeScript — had leaked through an npm package, exposing exactly how Anthropic's first-party tools authenticated with the backend and making it more pressing to lock down third-party tools that were spoofing those same patterns.

Anthropic offered a one-time credit equal to one month's subscription fee and a 30% discount on pre-purchased usage bundles to ease the transition. For light users, the credit covered the adjustment period, but for power users running multiple instances the new numbers simply did not work. The effect on activity was immediate:

experimentation stopped
viral sharing disappeared
search interest collapsed

This matches the sharp drop in Google Trends almost perfectly. The full policy mechanics and migration options after the cutoff are covered in Claude, OpenClaw, and the End of Flat Pricing for Agents.

OpenAI moves in the opposite direction

On the same day as the Anthropic ban, OpenAI publicly confirmed that ChatGPT Plus, Pro, and Team subscribers were entirely free to use their subscriptions to power OpenClaw through OAuth — including with models like GPT-5.3 Codex for complex coding tasks.

This was not accidental timing. By hiring Steinberger and explicitly opening their subscription gates, OpenAI positioned themselves as the developer-friendly alternative at the exact moment Anthropic cut off its most active community, securing the loyalty of the developers who were building the next generation of AI tools.

Phase 5. Where OpenClaw users actually went

Users did not disappear after the ban — they redistributed across a spectrum of alternatives depending on their technical depth and budget.

Direct usage of chat assistants

Many users moved back to direct chat interfaces, trading agent automation for the simplicity and reliability they had given up:

ChatGPT
Claude UI
Gemini

Are AI agents replacing traditional chat assistants

No — for most users, agents add complexity without enough reliability gains. The chat interface remains the default for daily use because it is faster to start, easier to debug when something goes wrong, and requires no infrastructure setup. Agents serve a committed minority of power users, not the general population. The AI developer tools ecosystem has evolved to fill this gap with tools that sit between raw agents and simple chat, giving developers structured assistance without full agentic overhead.

Cheaper model ecosystems

Power users with the technical ability to self-host migrated toward lower-cost alternatives:

Qwen
DeepSeek
other low-cost models accessible through Ollama for fully local setups

Which models are popular for low-cost AI experimentation

Models that offer lower pricing, fewer usage restrictions, and flexible deployment including local self-hosting absorbed the bulk of displaced OpenClaw power users. These ecosystems grew quietly rather than generating public hype, which is why the migration was largely invisible in trend data even as it represented a significant redistribution of compute demand.

Alternative agent frameworks

Developers who still needed agent capabilities switched to leaner approaches:

custom scripts tailored to specific workflows
lightweight frameworks with fewer dependencies
self-hosted solutions combining local models with minimal tooling

The key difference from OpenClaw is that these users optimized for cost and control rather than convenience, and built for sustainability rather than maximum automation at minimum price. This is the pattern common across the self-hosted AI systems ecosystem — provider independence treated as a design requirement, not an afterthought.

The overlooked factor — why cost is the real product

The most important insight from OpenClaw's trajectory is that cost functions as the real product in AI adoption.

Why is cost important in AI adoption

Because usage scales non-linearly with compute costs. When compute is cheap, experimentation explodes, innovation accelerates, and attention grows because viral sharing becomes economically rational. When compute becomes expensive, usage contracts to serious workflows only, casual users leave, and hype disappears almost overnight — which is precisely why token optimization and cost reduction strategies become critical skills once compute stops being subsidized.

OpenClaw demonstrated this rule in an unusually clear form: between February and April 2026, the software did not change, but the economics of running it did — and that single shift was enough to collapse the community in a matter of days.

OpenClaw was never the core story

OpenClaw functioned as a surface layer on top of more fundamental forces.

The real story involved three factors operating simultaneously:

access to Claude models at subscription prices rather than API rates
a five-to-one pricing mismatch between what users paid and what usage actually cost Anthropic
a policy correction that had to happen eventually given the scale of that mismatch

Once those underlying conditions changed, any tool that depended on them would show the same pattern — which is exactly why similar tools spiked and declined in lockstep, regardless of their individual quality or feature sets. Anthropic's decision also revealed something strategic: by blocking third-party clients while protecting Claude Code, the company chose to concentrate developer engagement inside its own first-party tooling at a moment when independent communities were iterating faster than any centralized lab.

The pattern repeats across AI

OpenClaw's trajectory is not unique — the same cycle has played out repeatedly across the AI ecosystem.

The same pattern appears in AutoGPT, BabyAGI, and other early agent frameworks that attracted massive attention and then faded as compute costs, reliability limits, or platform restrictions were enforced. The cycle is consistent:

New capability appears
Cheap or free usage emerges
Viral experimentation begins
Costs or limits are enforced
Attention collapses

Each cycle leaves behind a smaller, more committed user base and a clearer understanding of what actually works at scale — which is how progress compounds even through the boom-and-bust pattern.

OpenClaw vs Hermes Agent — what the trend data shows

The chart above compares worldwide Google Trends search interest for OpenClaw AI (blue) and Hermes Agent (red) over the past three months. OpenClaw peaked at an index of 100 in mid-March 2026 and collapsed sharply in April after the subscription cutoff. Hermes Agent barely registered during OpenClaw's peak, then gradually picked up interest as OpenClaw faded — reaching an index of around 40 in bursts through April, compared to OpenClaw's average of 49 and Hermes's average of 8.

Hermes Agent is an open-source framework built by Nous Research and released in February 2026. Unlike OpenClaw, which is optimized for broad reactive tool use across many integrations, Hermes is built around a learning loop: it generates reusable skills from successful task completions, refines them through continued use, and maintains a persistent model of the user across sessions. The result is an agent that improves the more it is used on the same task types, rather than approaching each job from the same baseline. It reached 95,600 GitHub stars in its first seven weeks.

The gap in the chart is significant. OpenClaw's hype surplus did not transfer to Hermes — it evaporated. Casual experimenters who had been running agents cheaply on Claude subscriptions simply left the space rather than migrating to an alternative. The users who did move to Hermes were the committed technical minority who needed persistent, self-hosted automation and were willing to set it up properly — which is exactly the kind of smaller, more sustainable user base that remains after every AI hype cycle collapses. For those users, Hermes production setup patterns are worth exploring.

Final takeaway — follow the economics, not the interface

OpenClaw did not rise because it was revolutionary — it rose because it unlocked something temporarily underpriced, and it fell not because it failed as a product but because that pricing advantage was removed by the platform it depended on.

This was not a product lifecycle. It was a pricing event.

Understanding this distinction is critical for predicting the next spike in AI tooling. The same pattern will repeat whenever a new compute subsidy appears, whether through a subscription loophole, a generous free tier, or a new open-weight model that undercuts established pricing. Track where compute is temporarily cheap and you will find the next wave of viral AI tools before the hype arrives.

Llama-Server Router Mode - Dynamic Model Switching Without Restarts

Rost — Mon, 27 Apr 2026 11:42:46 +0000

For a long time, llama.cpp had a glaring limitation:

you could only serve one model per process, and switching meant a restart.

That era is over.

Recent updates introduced router mode in llama-server, bringing something much closer to what people expect from modern local LLM runtimes:

dynamic model loading
unloading on demand
switching per request
no process restart

In other words: Ollama-like behavior, but without the training wheels.

If you are still deciding between local runtimes, cloud APIs, and self-hosted infrastructure, the
LLM hosting overview is a good starting point.

Prerequisites

Router mode requires a recent llama-server build — roughly post mid-2024. Older builds do not have the --models flag.

For install options (package manager, pre-built binaries, or full source build with CUDA), see the
llama.cpp quickstart.

Once you have llama-server, confirm your build supports router mode:

llama-server --help | grep -i models

If the --models flag appears, you are good. If it is absent, update to a newer build.

My current output of models-related help:

-cl,   --cache-list                     show list of models in cache
                                        Prefix/Suffix/Middle) as some models prefer this. (default: disabled)
                                        models with dynamic resolution (default: read from model)
                                        models with dynamic resolution (default: read from model)
                                        embedding models (default: disabled)
--models-dir PATH                       directory containing models for the router server (default: disabled)
                                        (env: LLAMA_ARG_MODELS_DIR)
--models-preset PATH                    path to INI file containing model presets for the router server
                                        (env: LLAMA_ARG_MODELS_PRESET)
--models-max N                          for router server, maximum number of models to load simultaneously
                                        (env: LLAMA_ARG_MODELS_MAX)
--models-autoload, --no-models-autoload
                                        for router server, whether to automatically load models (default:
                                        (env: LLAMA_ARG_MODELS_AUTOLOAD)

What router mode actually does

Router mode turns llama-server into a model dispatcher.

Instead of binding to a single model via -m, the server:

starts with no model loaded
receives a request that names a model
loads that model if it is not already in memory
runs inference
optionally unloads the model after the response, or keeps it warm for the next request

The key idea

You are no longer running:

./llama-server -m model.gguf

You are running:

./llama-server --models models.ini --port 8080

And letting the server decide what to load and when, based on what the client actually requests.

This matters because it means one persistent process can serve an entire fleet of models, with clients selecting the right one per task — a coding model, a chat model, a summarisation model — without any coordination overhead on your side.

Configuration: defining your models

This is where things are still a bit raw.

There is no fully stable official format yet, but current builds support INI-style model definitions via a config file.

Example models.ini

[llama3]
model = /opt/models/llama-3-8b-instruct.Q5_K_M.gguf
ctx-size = 8192
ngl = 35
threads = 8

[mistral]
model = /opt/models/mistral-7b-instruct-v0.3.Q4_K_M.gguf
ctx-size = 4096
ngl = 20
threads = 8

[qwen]
model = /opt/models/qwen2.5-coder-7b-instruct.Q5_K_M.gguf
ctx-size = 16384
ngl = 35
threads = 8

Each section name becomes the model identifier that clients use in the "model" field of their API requests.

Key config parameters

Parameter	What it controls
`model`	Absolute path to the GGUF file
`ctx-size`	Context window size in tokens. Larger values use more VRAM.
`ngl`	Number of GPU layers offloaded. Set to `0` for CPU-only; increase until you hit VRAM limits.
`threads`	CPU threads for the layers that remain on CPU.

Choosing the right ngl value depends on your GPU's available VRAM — for GPU selection and hardware economics, the compute hardware guide is a useful reference. To watch live VRAM consumption while dialing it in, see the GPU monitoring tools for Linux.

Starting the server with config

./llama-server --models /opt/llama.cpp/models.ini --port 8080

Confirm the server started correctly:

curl http://localhost:8080/v1/models | jq '.data[].id'

You should see each section name from your models.ini listed as a model ID.

A note on stability

The INI config interface is still evolving:

flags may change between commits
some parameters are only recognised by specific build configurations
documentation lags behind implementation

Pin to a specific llama.cpp commit if you need reproducibility across restarts.

API usage: switching models on request

Once the server is running, model switching happens through the standard OpenAI-compatible API. You simply set the "model" field.

List registered models

curl http://localhost:8080/v1/models

Completion request — first model

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3",
    "messages": [
      {"role": "user", "content": "Explain router mode in one paragraph"}
    ]
  }'

Switch to a different model — same endpoint, same port

curl http://localhost:8080/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen",
    "messages": [
      {"role": "user", "content": "Write a Python function that reads a CSV file"}
    ]
  }'

The server handles the unload/load cycle transparently. Your client code does not change — only the model field.

Python example

If you are using openai Python client:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8080/v1", api_key="not-needed")

# Use the coding model
response = client.chat.completions.create(
    model="qwen",
    messages=[{"role": "user", "content": "Write a Go HTTP handler"}],
)
print(response.choices[0].message.content)

# Switch to the chat model — same client, different model name
response = client.chat.completions.create(
    model="llama3",
    messages=[{"role": "user", "content": "What is the capital of Australia?"}],
)
print(response.choices[0].message.content)

What happens internally

When a request arrives for qwen and llama3 is currently loaded:

llama3 is unloaded from VRAM
qwen weights are read from disk and loaded into VRAM
inference runs
the next request determines whether to keep qwen loaded or swap again

This directly answers the common question:

How can a local LLM server switch models without restarting

By dynamically loading models per request, not binding at startup.

Systemd service: production-ready setup

Create a dedicated user and directories

sudo useradd --system --shell /usr/sbin/nologin --home-dir /opt/llama.cpp llm
sudo mkdir -p /opt/llama.cpp/models
sudo chown -R llm:llm /opt/llama.cpp

Copy your binary and model config into place:

sudo cp build/bin/llama-server /opt/llama.cpp/
sudo cp models.ini /opt/llama.cpp/

/etc/systemd/system/llama-server.service

[Unit]
Description=Llama.cpp Router Server
After=network.target

[Service]
Type=simple
User=llm
WorkingDirectory=/opt/llama.cpp
ExecStart=/opt/llama.cpp/llama-server --models /opt/llama.cpp/models.ini --port 8080
Restart=always
RestartSec=5

Environment=LLAMA_LOG_LEVEL=info

[Install]
WantedBy=multi-user.target

Enable and start

sudo systemctl daemon-reload
sudo systemctl enable llama-server
sudo systemctl start llama-server

Verify and inspect logs

sudo systemctl status llama-server

journalctl -u llama-server -f

On a successful start you will see lines indicating the server is listening and the model registry has been loaded. A quick sanity check:

curl -s http://localhost:8080/v1/models | jq '.data[].id'

Now you have a persistent service with auto-restart and centralised model switching — no manual process management required. If you want to apply the same pattern to other binaries, hosting any executable as a Linux service walks through the general approach.

The llama-server --metrics flag exposes a Prometheus-compatible endpoint. For llama.cpp-specific dashboards, PromQL queries, and alerting rules, see the LLM inference monitoring guide. For the broader observability setup, the observability guide covers the full stack.

Limitations you need to understand

Router mode is genuinely useful, but it comes with tradeoffs you should be clear about before relying on it in production.

Only one model in memory at a time

Even though multiple models are defined in models.ini, only one is resident in VRAM per worker at any given moment. Switching means a full unload-and-reload cycle.

switching means reload
latency spike is unavoidable
on a typical 7B model at Q5, a reload can take 3–10 seconds depending on disk speed and VRAM bandwidth

This answers another key question:

Does llama.cpp support serving multiple models at once

Not really. It supports multiple definitions, not simultaneous residency. If you need two models genuinely loaded in parallel, you need two processes on two separate GPUs.

For measured VRAM consumption and tokens-per-second across model sizes, the LLM performance benchmarks cover the full picture. For numbers specific to llama.cpp on a 16 GB GPU — dense and MoE models at multiple context sizes — see the 16 GB VRAM llama.cpp benchmarks.

No smart caching

Unlike Ollama, which maintains a warm pool and evicts models based on recency:

there is no automatic model eviction strategy
no background pre-warming
no priority queue for frequently used models

If you send alternating requests for llama3 and mistral, every single request triggers a reload. This is the fundamental cost of being closer to the metal.

Latency is unpredictable for mixed workloads

A well-behaved workload that uses one model consistently will be fast. A workload that interleaves multiple models will be slow. Plan your client routing logic accordingly — group requests by model where possible.

Config is not stable

The INI support exists and works in most recent builds, but it is not fully standardised. Flags and parameter names have changed across versions. If you upgrade llama-server, test your models.ini against the new build before deploying.

Llama.cpp vs Ollama: honest comparison

Feature	llama.cpp router	Ollama
Dynamic loading	Yes	Yes
Model switching	Yes	Yes
Built-in registry	Partial (INI)	Yes (pull-based)
Memory management	Basic	Advanced
Model eviction	None	TTL-based
UX polish	Low	High
OpenAI API compat	Yes	Yes
Control	Maximum	Opinionated
Config stability	Experimental	Stable

Opinionated take

Choose llama.cpp router mode when you want:

maximum control over runtime parameters per model
minimal process overhead
direct access to llama.cpp flags without abstraction layers
a hackable base for custom tooling

Choose Ollama when you want:

a stable, polished experience
automatic model downloading and versioning
smart keep-alive and eviction without configuration
batteries included from day one

Neither is wrong. The choice depends on how much you want to manage yourself.

If you go with Ollama, the Ollama CLI cheatsheet covers day-to-day commands. For a broader comparison that also includes vLLM, LM Studio, and LocalAI, see how different local runtimes compare in 2026.

Llama.cpp vs llama-swap

llama-swap is an external orchestrator that sits in front of one or more llama-server instances:

it intercepts requests and inspects the model field
it starts the appropriate llama-server process for that model
it shuts down idle instances after a configurable timeout
it proxies the request through once the model is ready

For a hands-on setup, see the llama-swap quickstart.

Key difference

Aspect	router mode	llama-swap
Built-in	Yes	No (separate binary)
Maturity	Experimental	More stable
Flexibility	Limited	High
Control layer	Internal	External proxy
Per-model config	INI file	YAML file
Process model	Single process	One process per model

When to use llama-swap

llama-swap gives you process-level isolation per model, which means a crash in one model instance does not affect others. It also lets each model run with completely independent llama-server flags.

Use it if you need:

better lifecycle control and isolation
smarter switching logic with configurable idle timeouts
more predictable latency (each model has a warm process after first load)
production stability today, not eventually

When native router mode is enough

Use the built-in router if you want:

zero external dependencies
a single process to manage
simpler deployment (one binary, one config file)
minimal stack for dev or single-user setups

Final thoughts

Router mode is a meaningful step forward for llama-server.

It answers the long-standing demand:

What is router mode in llama.cpp server

It is the missing layer that turns a static binary into a dynamic inference service — one process that can field requests for a whole catalogue of models.

But it is not finished.

Today it is:

powerful enough for real workloads
promising as a foundation for more sophisticated routing
slightly rough around the config and stability edges

If your workload is predictable and you can group requests by model, router mode works well today. If you need production-grade reliability and per-model isolation, reach for llama-swap while the native implementation matures.

Either way, you get Ollama-like behavior, without hiding the machinery.

Claude Skills and SKILL.md for Developers: VS Code, JetBrains, Cursor

Rost — Sat, 25 Apr 2026 08:10:03 +0000

Most teams misuse Claude Skills in one of two ways. They either turn SKILL.md into a dumping ground, or they never graduate from giant copy-pasted prompts.

Both approaches are sloppy. If you want Skills to work in a real dev workflow, you need to treat them like code and operations logic, not like prompt poetry.

Claude Skills are directories anchored by SKILL.md, with optional scripts, references, and assets. They work because of progressive disclosure. The agent starts by loading only compact metadata such as the skill name and description, then reads the full instructions only when the task matches. That lets an agent keep many skills available without bloating every session from the start.

Anthropic's own guidance makes the intended division of labour pretty clear. CLAUDE.md is for durable, always-on project context. Skills are for reusable knowledge, playbooks, and invocable workflows that should load on demand. Claude Code even folded old custom commands into the same mechanism, so legacy .claude/commands/*.md files still work, but Skills are now the better long-term shape — and the most reusable building block in any AI-powered development workflow.

When to Use Claude Skills: CLAUDE.md vs Skills vs Hooks

A Claude Skill is worth creating when you keep pasting the same checklist, the same deployment playbook, the same code review rubric, or the same internal API gotchas into chat. Anthropic explicitly recommends creating a skill when you keep reusing the same procedure, or when a section of CLAUDE.md has grown into a process rather than a fact. That is the practical answer to the FAQ question "What is a Claude Skill and when should you use one". Use a Skill for repeatable procedure, not for general taste or broad repo rules.

The real win is control over context cost and behaviour. A good Skill is loaded only when relevant, while a bloated CLAUDE.md is loaded every session. Anthropic recommends keeping CLAUDE.md short and moving domain knowledge or procedures into Skills precisely because on-demand loading keeps the agent focused on the task in front of it.

My opinionated rule is simple. If the instruction should apply every single session, it belongs in CLAUDE.md. If the instruction is a reusable method, checklist, or workflow that matters only sometimes, it belongs in a Skill. If the action must happen automatically on every matching event, it probably belongs in a hook, not a Skill. Anthropic's feature overview frames those tools in almost exactly that layering model.

Layer	Tool	When to use
`CLAUDE.md`	Always loaded	Project facts, durable conventions, repo-wide rules
Skill	Loaded on demand	Repeatable procedures, playbooks, domain checklists
Hook	Event-triggered	Automatic side effects on file save, commit, or session start

A practical smell for each: if you find yourself pasting the same instructions into every chat, that is a Skill. If a CLAUDE.md section has grown into a step-by-step process, extract it into a Skill. If you want something to fire silently every time a file is saved, write a hook instead.

Claude Skills IDE Support: VS Code, JetBrains, Cursor, and Codex

Claude Code runs across CLI, Desktop, VS Code, JetBrains, web, and mobile-related remote control flows. Anthropic describes the CLI as the most complete local surface, while the IDE integrations trade some CLI-only capabilities for editor-native review, file context, and tighter workflow ergonomics. Configuration, project memory, and MCP servers are shared across the local surfaces, so your .claude setup follows you rather than being trapped in one editor.

For VS Code, Anthropic says the extension is the recommended interface inside the editor. It provides plan review, inline diffs, file mention support, and integrated access to the CLI. The same install flow also exposes a direct path for Cursor. For JetBrains, the current supported list includes IntelliJ IDEA, PyCharm, Android Studio, WebStorm, PhpStorm, and GoLand, with diff viewing, selection sharing, file-reference shortcuts, and diagnostic sharing built into the plugin.

JetBrains support is better than many developers realise. If you run claude from the IDE's integrated terminal, the integration features are active automatically. If you start from an external terminal, Anthropic documents the /ide command to connect Claude Code back to the JetBrains session, and it explicitly recommends launching from the same project root so Claude sees the same files your IDE sees. If you use auto-edit modes in JetBrains, Anthropic also warns that IDE configuration files can become part of the editable surface, so manual approvals are the safer default in that environment.

Now the bigger point. Claude Skills are not only a Claude Code thing. Agent Skills is an open standard. The official Agent Skills quickstart says the same skill can work in VS Code with GitHub Copilot, Claude Code, and OpenAI Codex, and OpenAI's own Codex docs say Skills are available in the Codex CLI, IDE extension, and app. The Agent Skills implementation guide adds an important portability detail: .agents/skills has emerged as the cross-client convention, while some clients also scan .claude/skills for pragmatic compatibility.

So here is the practical compatibility rule I recommend. If you are building for Claude Code first and only, author in .claude/skills. If you genuinely want cross-client portability, target the open Agent Skills shape and use .agents/skills as the canonical path. Do not pretend those two goals are identical. They are related, not identical.

Quick compatibility reference:

Client	Skills path	Notes
Claude Code CLI	`.claude/skills/` or `~/.claude/skills/`	Most complete surface; full `allowed-tools` support
VS Code + Claude extension	`.claude/skills/`	Inline diffs, plan review, file mention
Cursor	`.claude/skills/`	Same install path as VS Code
JetBrains (IDEA, PyCharm, etc.)	`.claude/skills/`	Run `claude` from IDE terminal or use `/ide` to reconnect
GitHub Copilot, OpenAI Codex	`.agents/skills/`	Open Agent Skills standard; cross-client portability
Claude.ai web	Upload via UI	Dir name must match `name` field; 200-char description cap

SKILL.md File Structure, Folder Layout, and Storage Locations

A proper Skill is a folder, not a random markdown file sitting at repo root. The core specification requires a directory with a SKILL.md file and allows optional scripts/, references/, and assets/ directories. SKILL.md must contain YAML frontmatter followed by markdown instructions. In the spec, name and description are required, name is limited to 64 characters using lowercase letters, numbers, and hyphens, compatibility is only for real environment requirements, and allowed-tools is explicitly experimental across implementations.

Claude Code is a bit looser than the portable spec because it can derive a name from the directory and fall back to the first paragraph when description is missing. You should not rely on that if you care about portability or predictability. Claude.ai requires the directory name to match the name field, and its custom-skill upload path caps descriptions at 200 characters even though the broader spec allows much more. The portable choice is to set an explicit name, keep the directory identical, and write a precise description that fits in tight limits. That answers the FAQ topic "What should a SKILL.md file contain" without hand-waving.

Start from a structure this boring:

repo/
  .claude/
    skills/
      review-pr/
        SKILL.md
        scripts/
          review.sh
        references/
          checklist.md
        assets/
          comment-template.md

If portability across Skills-compatible clients matters more than Claude Code convenience, keep the same internal shape and swap .claude/skills/ for .agents/skills/. The folder structure is the same idea either way.

For Claude Code, the storage locations are straightforward. Project skills live at .claude/skills/<skill-name>/SKILL.md. Personal skills live at ~/.claude/skills/<skill-name>/SKILL.md. Plugin-distributed skills live under <plugin>/skills/<skill-name>/SKILL.md. Anthropic documents precedence across the built-in scopes as enterprise over personal over project, while plugin skills avoid collisions by using a namespaced form such as plugin-name:skill-name. On Windows, ~/.claude resolves to %USERPROFILE%\.claude, and CLAUDE_CONFIG_DIR can relocate the whole base directory.

The choice between project and personal scope is straightforward. Use .claude/skills/ inside the repo when the Skill is tightly coupled to that codebase — for example, a deploy playbook that knows your specific cluster names or a review rubric tuned to your team's conventions. Use ~/.claude/skills/ for Skills that travel with you across projects: personal checklists, generic changelog generators, preferred debugging workflows. Anything you would put in a dotfiles repo belongs in personal scope.

A few sharp edges are worth memorising. SKILL.md must be named exactly with that casing. Anthropic's PDF guide recommends kebab-case folder names and explicitly says not to place a README.md inside the skill folder, because the operative documentation should live in SKILL.md or references/. That same guide also stresses that SKILL.md naming is case-sensitive. These are boring constraints, but boring constraints are what make tooling reliable.

Claude Code also does the right thing for monorepos. It automatically discovers nested .claude/skills/ directories when you work inside subdirectories, which is ideal for package-level or service-level skills. It also watches existing skill directories for live changes during the current session. The one restart trap is creating a top-level skills directory that did not exist when the session started. Anthropic documents that as the case where you do need to restart so the new directory can be watched.

Claude Skills Best Practices: Descriptions, Scripts, and Scope

The fastest way to create a useless Skill is to ask an LLM to invent one from generic training knowledge. Anthropic's best-practices guide warns against exactly that. The valuable bits are the domain-specific corrections, edge cases, tool choices, and conventions the model would not reliably invent on its own. The right workflow is to solve the task once with the agent, correct it until it works, then extract the method into a Skill.

Scope the Skill like a good function, not like a wiki. Anthropic says Skills should encapsulate a coherent unit of work. Too narrow, and you force multiple skills to stack for one task. Too broad, and the agent cannot activate them precisely. The best-practices guide is blunt that overly comprehensive skills can hurt more than they help because the model chases irrelevant instructions and loses the signal.

Description quality is not a cosmetic concern. It is the routing layer. Both Anthropic and the Agent Skills docs say the description field is the primary mechanism the model uses to decide whether to load a Skill at all. Good descriptions say what the Skill does, when to use it, and the trigger phrases or file types a user would actually mention. Bad descriptions are vague, overly technical, or broad enough to match nonsense. That is the real answer to the FAQ question "Why is a Claude Skill not triggering". Usually the router is bad, not the model.

The contrast is clear side by side:

Bad descriptions — too vague to route reliably:

Helps with code review — matches everything, disambiguates nothing
Useful for development tasks — broader than a search query
Assists with writing — not a router, just a category label

Good descriptions — specific trigger language:

Review pull requests for security issues, migration risk, and missing tests. Use when reviewing a PR, git diff, or release critical change.
Generate a changelog from git log output. Use when preparing a release, writing release notes, or summarising commits since last tag.
Scaffold a new Go HTTP handler with request validation and error middleware. Use when adding a new endpoint or route to a Go service.

The pattern is the same each time: state what the Skill does, name the exact user phrases that should activate it, and optionally name file types or tools that are relevant. If your description would match a generic Google query, it is not specific enough.

If a workflow has side effects, make it manual. Claude Code exposes that directly. disable-model-invocation: true makes a Skill user-invoked only, which Anthropic recommends for actions like deploys, commits, or outbound messages. user-invocable: false goes the other way and hides the Skill from the slash menu while still letting Claude use it as background knowledge. That answers the FAQ topic "When should a skill be manual instead of automatic" in one sentence: manual for risk, automatic for safe repeatable guidance.

Keep SKILL.md small enough to stay intelligible. Anthropic recommends keeping it under 500 lines and around 5,000 tokens, then moving detailed material into references/ or similar files with explicit loading instructions. "Read references/api-errors.md if the API returns a non-200" is a good pattern. "See references/" is lazy. Claude Code also injects the rendered Skill into the conversation as a message and does not keep re-reading the file on later turns. After context compaction, only recent Skill content is carried forward within token budgets. Huge Skills are therefore not merely ugly. They are brittle over long sessions.

A good SKILL.md can stay very plain:

---
name: review-pr
description: Review pull requests for security issues, migration risk, and missing tests. Use when reviewing a PR, git diff, or release critical change.
compatibility: Designed for Claude Code. Requires git and gh.
disable-model-invocation: true
allowed-tools: Bash(git diff *) Bash(gh pr diff *) Read Grep Glob
---
# Review PR

Read references/checklist.md before running any commands.

1. Collect the diff and changed files.
2. Flag correctness, security, and test coverage issues.
3. Return findings grouped by severity with file references.
4. Suggest the smallest safe fix first.

Use scripts when determinism matters more than eloquence. The Skills scripts guide is excellent here. It says agent-facing scripts must avoid interactive prompts, document usage through --help, emit helpful error messages, prefer structured output such as JSON or CSV on stdout, send diagnostics to stderr, and support retry-safe use. It also recommends pinning one-off tool versions and describing runtime requirements explicitly in SKILL.md or the compatibility field rather than assuming the environment has the right packages.

A minimal but correct agent-facing script looks like this:

#!/usr/bin/env bash
# scripts/collect-diff.sh — called by review-pr skill
# Usage: collect-diff.sh <base-ref> [<head-ref>]
set -euo pipefail

BASE="${1:?Usage: collect-diff.sh <base-ref> [<head-ref>]}"
HEAD="${2:-HEAD}"

# Structured output to stdout so the agent can parse it
git diff "${BASE}...${HEAD}" --stat --name-only \
  | jq -Rs '{
      "changed_files": split("\n") | map(select(length > 0))
    }' \
  || { printf '{"error":"git diff failed"}\n' >&2; exit 1; }

Three things make this agent-safe. set -euo pipefail ensures the script exits loudly on any failure rather than silently proceeding. JSON on stdout gives the agent a format it can parse without guessing. Diagnostics go to stderr so the agent's stdout stream stays clean. None of this is clever. All of it is necessary.

One subtle trap is allowed-tools. In the spec it is experimental and support varies. In Claude Code it pre-approves specific tools while the Skill is active, but it does not restrict the universe of callable tools, and deny rules still belong in Claude Code permissions. In the Claude Agent SDK, Anthropic explicitly says the allowed-tools frontmatter in SKILL.md does not apply, so SDK apps must enforce tool access in the main allowed_tools or allowedTools configuration instead. If you ignore that difference, your Skill will behave differently in the CLI and in SDK-powered automation.

One more advanced pattern is worth stealing. When a workflow would flood your main thread with logs, file searches, or long research output, Claude Code lets a Skill run in a forked subagent using context: fork and an agent such as Explore. Anthropic shows this for research workflows, where the heavy lifting happens in isolated context and the main conversation gets the summary. For deep codebase exploration, that is a much better design than a giant inline Skill that pollutes the main session.

A forked Skill looks like this in frontmatter:

---
name: explore-codebase
description: Deep exploration of an unfamiliar codebase. Use when onboarding to a new repo, auditing architecture, or mapping module dependencies.
context: fork
agent: Explore
compatibility: Requires Claude Code CLI.
---
# Explore Codebase

1. Walk the directory tree and summarise the top-level modules.
2. Identify the main entry points and their responsibilities.
3. Map the dependency graph between packages.
4. Return a structured summary to the main session — not the raw file list.

The key line is context: fork. Without it, the exploration output lands inline in your conversation. With it, the subagent runs in its own context window and hands back a summary. The difference matters on large repos where exploration alone can consume thousands of tokens.

Testing Claude Skills: Triggers, Correctness, and Baseline Comparisons

A Skill is not tested because one happy-path demo worked once. Anthropic's guide breaks testing into three layers: manual testing in Claude.ai, scripted testing in Claude Code, and programmatic testing via the Skills API. The recommended evaluation areas are triggering, functional correctness, and performance against a baseline without the Skill. That is also the best answer to the FAQ question "How do you test whether a skill is reliable". You test route selection, output quality, and efficiency, not just whether the model sounded confident.

The official eval guidance gives a clean structure for test cases. Each case should include a realistic user prompt, a human-readable description of the expected output, and optional input files. The docs store those in evals/evals.json inside the Skill directory, which is a sensible convention even if you roll your own harness.

Use a fixture file and a no-nonsense eval layout like this:

{
  "skill_name": "review-pr",
  "evals": [
    {
      "id": 1,
      "prompt": "Review this PR for security issues and missing tests",
      "expected_output": "Findings grouped by severity with file references and at least one test recommendation.",
      "files": ["evals/files/pr-diff.patch"]
    },
    {
      "id": 2,
      "prompt": "Summarise last week's commits",
      "expected_output": "The skill should not activate.",
      "files": []
    }
  ]
}

My own testing rule is harsher than most teams use, but it lines up with the official guidance. Every serious Skill should have should-trigger queries, should-not-trigger queries, at least one edge-case test, and a baseline comparison without the Skill. Anthropic's examples compare tool calls, failed API calls, clarification loops, and token use with and without the Skill because "works" is not the same as "improves the workflow".

If you test through the Claude Agent SDK, remember the plumbing. Skills are filesystem artefacts there, not programmatic registrations. Anthropic says you must enable the "Skill" tool and load the relevant filesystem settings through settingSources or setting_sources. If you omit user or project, or point cwd at the wrong place, the SDK will not discover the Skill. Anthropic even recommends asking "What Skills are available?" as a direct discovery check.

Also test on the model and client you actually intend to ship. The open Agent Skills quickstart explicitly warns that tool-use reliability varies across models, and some models may answer directly instead of executing the command the Skill intends. That is not always a Skill design problem. Sometimes it is a model-selection problem, and your test matrix should expose it.

Claude Skills Troubleshooting: Common Failures and Fixes

When a Skill misbehaves, assume packaging before intelligence. The most common failures are still the boring ones.

If the Skill is not found at all, verify the file is named exactly SKILL.md, with the right case, inside the correct directory. Anthropic's troubleshooting guide calls out filename case explicitly, and its Claude Code and SDK docs point you straight at .claude/skills/*/SKILL.md and ~/.claude/skills/*/SKILL.md as the first checks.
If frontmatter is invalid, check the YAML delimiters and quotes first. Anthropic's examples show the classic mistakes: missing ---, unclosed quotes, or invalid names with spaces and capitals. Skill names should be lowercase and hyphenated.
If the Skill exists but does not trigger, the description is usually too vague. Claude Code's own troubleshooting says to include keywords users would naturally say, verify the Skill appears when you ask "What skills are available?", and try rephrasing closer to the description. Anthropic's PDF guide adds a great diagnostic trick: ask Claude when it would use the Skill and listen to how it paraphrases the description back to you.
If the Skill triggers too often, narrow the scope. Anthropic recommends making the description more specific, adding negative triggers, and using disable-model-invocation: true for workflows you want only by explicit command. Over-triggering is usually just under-specified routing language.
If the Skill seems to lose influence in long sessions, remember that descriptions can be shortened in the Claude Code catalogue when many skills are present, and invoked Skills are later carried within token budgets after compaction. Anthropic recommends front-loading keywords in the description, trimming excess text, and, for Claude Code specifically, adjusting SLASH_COMMAND_TOOL_CHAR_BUDGET if description listings are being squeezed too aggressively.
If a bundled script hangs or behaves erratically, check whether it expects interactive input. The scripts guide says agents run in non-interactive shells, so TTY prompts, password dialogs, and confirmation menus are design bugs. Accept input through flags, environment variables, or stdin and make failures explicit.
If the SDK does not see your Skill, confirm that allowed_tools includes "Skill", that settingSources or setting_sources contains user and or project, and that cwd points at the directory that actually contains .claude/skills/. Without that setup, the Skill system is not enabled no matter how correct your markdown looks.
If an MCP-backed Skill loads but the tool calls fail, Anthropic's troubleshooting checklist is sensible: verify the MCP server is connected, confirm authentication and scopes, test the MCP tool directly without the Skill, then check the exact tool names because they are case-sensitive.

The boring truth is that good Claude Skills look like good operational engineering. Clear names. Small files. Explicit triggers. Deterministic scripts where needed. Real tests. If your Skill reads like a crisp runbook, the agent has a fighting chance. If it reads like a brainstorm, you have simply hidden chaos in a folder.

Pause Scripts with 'Press Any Key' in Bash, CMD, PowerShell, and macOS

Rost — Sat, 25 Apr 2026 08:09:59 +0000

Batch files and shell scripts often need a short wait so a double-clicked window or installer log stays visible. Windows CMD has a dedicated pause command. Unix shells use read.

PowerShell sits in the middle and needs an explicit pattern.

This page collects portable snippets and the usual pitfalls (pipes, SSH without TTY, CI).

For more shell references, see the Bash cheat sheet and PowerShell cheatsheet.

For broader tooling workflows, visit Developer Tools: The Complete Guide to Modern Development Workflows.

When to pause (and when not to)

Use a pause when a human is watching an interactive terminal and you want to avoid an instant exit—for example after a .bat file is double-clicked, or after a local maintenance script prints a summary.

Skip pauses in cron, systemd services, CI pipelines, and most SSH one-liners. There is often no keyboard attached and stdin may not be a terminal, so waiting for input can hang forever. In Bash and POSIX sh, test with [ -t 0 ] (or test -t 0) before prompting.

Windows CMD

The pause command prints a localized line such as “Press any key to continue . . .” and waits for a keypress.

:: save as pause-demo.bat
@echo off
echo Hello from CMD
pause

If output is redirected, behavior can differ; for scripts that must run logged to a file, consider timeout /t N for a timed delay instead of an interactive pause.

choice is useful when you want a timed wait or specific keys (menu scripts). It is a separate topic from pause but often appears in the same batch workflows.

PowerShell

PowerShell has no single pause alias that matches CMD in every host. Two common patterns follow.

Wait for Enter only

Simple and works in many hosts including some IDEs.

# pause-demo.ps1
Read-Host 'Press Enter to continue'

This is not “any key”—only Enter counts.

Wait for any key (Windows console)

In Windows PowerShell running in a normal console host, ReadKey waits for a physical key:

# pause-any-key.ps1
Write-Host 'Press any key to continue...'
$null = $Host.UI.RawUI.ReadKey('NoEcho,IncludeKeyDown')

If $Host.UI or RawUI is not available (some non-interactive hosts, remoting, or constrained environments), this can fail. Wrap such calls in try / catch or detect [Console]::KeyAvailable / host capabilities when you need robustness.

PowerShell 7 on non-Windows platforms may not offer the same ReadKey experience; prefer Read-Host or shell-native read in those cases.

Bash (Linux and macOS)

Classic “any key” style with a visible prompt and no echo of the key:

#!/usr/bin/env bash
read -r -n 1 -s -p $'Press any key to continue...\n'

-n 1 — read one character
-s — silent (no echo)
-r — raw (backslash not special)
-p — prompt string

With a friendly guard for automation:

#!/usr/bin/env bash
if [ -t 0 ]; then
  read -r -n 1 -s -p $'Press any key to continue...\n'
fi

macOS notes

Terminal.app and iTerm2 behave like other Unix terminals for Bash. Apple’s default login shell is often Zsh; for interactive Zsh you may use read -k 1 in scripts explicitly run by Zsh. For maximum portability across Linux and macOS, stay with Bash or document #!/usr/bin/env bash at the top of the script.

POSIX `sh` (portable “press Enter”)

POSIX read does not require read -n, which is not POSIX. The portable pattern is “press Enter to continue”:

#!/bin/sh
printf 'Press Enter to continue... '
read -r _

That is widely supported on dash, ksh, and ash-based systems. True single-character “any key” without Bash extensions is messier; if you need it on minimal sh, document Bash or use stty-based approaches with care (terminal state, portability).

Cross-platform branching

Installer scripts sometimes branch on OS:

Windows CMD — pause
PowerShell — ReadKey or Read-Host
Unix — read with [ -t 0 ] guard

In mixed environments, keep the “interactive only” guard so servers and CI never block.

Useful links

GNU Bash manual — Bash Builtins — read
Microsoft Learn — Read-Host and console APIs for advanced hosts

OpenClaw Plugins — Ecosystem Guide and Practical Picks

Rost — Mon, 20 Apr 2026 09:51:41 +0000

This article is about OpenClaw plugins — native gateway packages that add channels, model providers, tools, speech, memory, media, web search, and other runtime surfaces.

The rest of the piece covers discovery, packaging, CLI lifecycle, maturity, security, and concrete plugin picks.

OpenClaw skills matter for navigation and safety because ClawHub and announcement text often say "skills" when they mean installable agent packs and workflows. Those are related to the same registries you use for plugins, but they are not the same mechanism as a validated openclaw.plugin.json package. The glossary below keeps the vocabulary straight; the OpenClaw skills guide goes deeper on authoring, moderation, usage patterns, and per-role stacks.

At the same time, the public plugin ecosystem is uneven.
The strongest parts are still bundled first-party surfaces and a small set of community plugins with visible maintenance and usage. The weaker parts are the business-automation edge cases that look impressive in demos but still have thin public adoption signals, including skill-oriented repos that are not yet mature native plugins.

If you want the short version up front, this is it.
In OpenClaw today, the "actually useful" plugin layer is mostly about boring wins: browser access, web extraction, memory, provider routing, voice, channels, observability, and workflow triggers. The categories that sound most enterprise-friendly — CRM, lead generation, inbox automation, calendar orchestration — do exist publicly, but the verified native-plugin surface is still much thinner and less battle-tested than the rest of the stack. That is not a criticism so much as a maturity signal.

Glossary (plugins, extensions, skills)

OpenClaw plugins — Native gateway packages installed with openclaw plugins …, validated through openclaw.plugin.json, and able to register channels, providers, tools, memory backends, and other hooks inside the gateway process.
OpenClaw extensions — Workspace and global directories OpenClaw scans as plugin roots before bundled defaults (extension paths under the workspace, then ~/.openclaw). This is a layout and discovery idea. It is not a different kind of artifact from plugins; it is where plugin packages are loaded from.
OpenClaw skills — Agent-facing packs and workflows often published for OpenClaw-style agents and listed on ClawHub alongside packages. Security and moderation messaging frequently refers to "skills" because that layer has its own adoption and abuse history. Treat skills as a related install surface, not as a synonym for "native plugin" unless the listing is actually a plugin package with a manifest.

When OpenClaw imports content from Codex, Claude, or Cursor ecosystems, upstream docs often call those bundles, not native plugins. Bundles map to selective features and a narrower trust boundary than full plugins. If you mix bundles, skills marketing, and native OpenClaw plugins without that distinction, the ecosystem looks broader than it actually is.

Why this ecosystem matters

Inside the codebase and CLI, the extension story is still expressed as plugins. Discovery walks explicit config paths, then extension directories, then bundled plugins — same capability type, different roots. Skills enter the picture when you browse ClawHub or read incident writeups, not when you reason about slot selection for memory or contextEngine.

The plugin system is also opinionated in a useful way. OpenClaw does not treat plugins as a cosmetic add-on layer. It uses them for concrete runtime ownership: channels, model providers, tools, memory backends, context engines, speech, realtime voice, media understanding, image generation, video generation, web fetch, and web search. Some of those ship bundled inside OpenClaw, while others are external packages published by the community on npm or ClawHub.

That is why the plugin ecosystem matters more than it first appears. In practice, plugin choice determines not just integrations, but also how the assistant searches, remembers, calls, routes, fetches, traces, and survives long-running sessions. For a technical blog, that is the important frame. Not "which package looks cool", but "which package owns a meaningful runtime surface".

How the plugin system actually works

Under the hood, OpenClaw discovers plugins in a fixed order, and first match wins. It looks at explicit config paths first, then workspace extension directories, then global extensions under ~/.openclaw, and finally bundled plugins that ship with OpenClaw. Workspace-origin plugins are disabled by default, restrictive allowlists can block even bundled plugins, and some capability classes are exclusive slots, notably memory and contextEngine.

That slot model is one of the least flashy but most important parts of the system. It means plugins are not only additive. In some categories they are selectors. memory-core can be the active memory plugin, memory-lancedb can replace it, and a context engine such as lossless-claw can replace the default legacy context engine. This is why memory plugins tend to matter operationally more than UI-facing plugins. They change how the assistant thinks across time, not just where it sends messages.

Native plugins also have a fairly strict packaging model. A package advertises its plugin entrypoints and setup metadata through package.json, while openclaw.plugin.json is the manifest OpenClaw uses to validate plugin identity and config before executing plugin code. That manifest is not decorative. Missing or invalid manifests are treated as plugin errors and block config validation. The platform is clearly trying to fail early rather than load first and hope later.

The SDK surface is broader than many blog posts imply. Plugin hooks can intercept model resolution, agent lifecycle, message flow, tool execution, sub-agent coordination, and gateway lifecycle, and the docs state that the SDK exposes 28 hooks. That is enough power to build real runtime products, but it is also enough power to create runtime surprises if the plugin is immature.

Where to get plugins and how the lifecycle works

Plugin installs always go through the openclaw plugins commands below. ClawHub lists both native plugin packages and OpenClaw skills-style entries, so read each listing for manifests and supported install paths — this section is only about the plugin path.

The public repository layer is straightforward. ClawHub is the canonical discovery surface for community plugins and many skills listings, and OpenClaw can install plugins from ClawHub, npm, local paths, local archives, and supported marketplaces. For bare package names, OpenClaw checks ClawHub first and falls back to npm automatically. That alone answers one of the common ecosystem questions: yes, there is a public repository story, but it is split between the official registry layer and npm.

The install and removal lifecycle is also clearer than the ecosystem chatter makes it sound. The CLI supports listing, inspecting, enabling, disabling, uninstalling, doctoring, and updating plugins. Config changes require a gateway restart, although the default openclaw gateway path may auto-restart after a config write lands. In practice, temporary removal is disable, hard removal is uninstall, and validation failures are designed to fail closed instead of leaving half-installed state behind.

The commands you actually need are simple:

openclaw plugins list
openclaw plugins inspect <id>
openclaw plugins install <package>
openclaw plugins enable <id>
openclaw plugins disable <id>
openclaw plugins uninstall <id>
openclaw gateway restart

Those commands are the stable part. The interesting parts are the safety rails around them. OpenClaw recommends pinned versions for plugin installs, uses --ignore-scripts for npm dependency installs, validates compatibility metadata such as pluginApi and minGatewayVersion before archive installs, and ships a built-in dangerous-code scanner with a break-glass override named --dangerously-force-unsafe-install. That is a more serious security posture than many agent ecosystems currently offer.

One subtle detail is worth calling out. ClawHub install counts are useful, but they are not absolute ecosystem census numbers. The documentation says install counts are computed when logged-in users run clawhub sync, and stale roots stop counting after 120 days. That makes ClawHub usage counters directionally useful, especially for ranking, but not a universal measure of actual adoption.

Maturity, support, and security reality

The maturity story is split in two. First-party bundled plugins are the safest default because they live inside the main OpenClaw release train, share the same compatibility model, and benefit from a very large public core repository footprint. At crawl time, the main openclaw/openclaw repository showed roughly 359k GitHub stars, which is the strongest public popularity signal anywhere in this ecosystem. Community plugins can absolutely be useful, but they are not all equal and they do not inherit that maturity automatically.

OpenClaw's own community-plugin page is refreshingly blunt about the quality bar. The project asks for a public GitHub repository, working installation through openclaw plugins install, setup and usage docs, and active maintenance. Low-effort wrappers, unclear ownership, or unmaintained packages may be declined. That tells you a lot about where the team has already seen ecosystem failure.

Security is the part where opinion should replace hype. The docs themselves say to treat OpenClaw plugin installs like running code. ClawHub exposes moderation hooks, stars, comments, and usage signals, and the broader OpenClaw security response has moved toward stronger package scrutiny. The team announced VirusTotal scanning for all ClawHub skills, and independent security research documented malicious ClawHub campaigns and large-scale insecure credential handling in early 2026. Those incidents were centered on OpenClaw skills and skill-style listings, not every native plugin path, but they are still the correct backdrop for evaluating the whole installable ecosystem. The lesson is simple: the extension perimeter — config, OpenClaw extensions directories, and anything you install from a registry — is now part of the attack surface.

A second, more nuanced security point is that safer ecosystems still produce false positives. OpenClaw's dangerous-code scanner is heuristic, and public plugin maintainers have already had to react to scanner warnings and installation friction. That is not a sign that the scanner is wrong to exist. It is a sign that "scanner clean" and "safe" are not identical concepts, and that human review still matters for nontrivial plugins.

Useful plugins worth tracking right now

What follows is the pragmatic list, not the maximal list. For bundled first-party plugins that do not have standalone repos, the popularity metric below uses the OpenClaw core repo star count as the proxy. For community plugins, the popularity metric uses the canonical public GitHub repo star count visible at crawl time.

Tools and web access

browser

URL: https://docs.openclaw.ai/tools/browser

This is the default serious-tool plugin because it gives the agent a managed isolated browser profile and an attach-to-user-browser mode when logged-in human sessions matter. That is more useful than another generic web search wrapper. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.
firecrawl

URL: https://docs.openclaw.ai/tools/firecrawl

Firecrawl is useful because it can act as a web_search provider, expose explicit firecrawl_search and firecrawl_scrape tools, and serve as a web_fetch fallback for JS-heavy or anti-bot pages. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.
tavily

URL: https://docs.openclaw.ai/tools/tavily

Tavily is still one of the cleaner structured-search options because it exposes both search and extraction and is explicitly optimized for LLM consumption. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.
exa

URL: https://docs.openclaw.ai/tools/exa-search

Exa is the best fit when you want hybrid search modes plus extraction in one provider without immediately jumping to browser automation. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.

Integrations and collaboration

matrix

URL: https://docs.openclaw.ai/channels/matrix

Matrix is one of the more complete bundled collaboration plugins because it already supports DMs, rooms, threads, media, reactions, polls, location, and E2EE through matrix-js-sdk. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.
msteams

URL: https://docs.openclaw.ai/channels/msteams

Teams matters because it is one of the few enterprise channels with a real first-party path, including Azure Bot setup, tenant credentials, default webhook shape, and group-chat policy controls. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.
wecom

URL: https://github.com/WecomTeam/wecom-openclaw-plugin

WeCom is one of the stronger community channel plugins because it is officially maintained by the Tencent WeCom team and supports direct messages, group chats, streaming replies, proactive messaging, and both Bot and Agent operating modes. Popularity: about 365 GitHub stars.
openclaw-discourse

URL: https://github.com/pranciskus/discourse-openclaw

Discourse is a good example of a plugin that is small but useful. It focuses on searching, reading, filtering, finding unanswered topics, and optionally writing back to the forum, which is exactly what support and community workflows need. Popularity: about 10 GitHub stars.

A side note here is that Slack is less interesting in a plugins article than many people expect, because Slack is already treated as a built-in channel surface in current OpenClaw documentation and marketing copy. Teams and WeCom are more revealing plugin picks because they show where external or bundled channel ownership still matters visibly.

Memory and context

memory-lancedb

URL: https://docs.openclaw.ai/tools/plugin

This is the practical long-session memory pick in the bundled set. OpenClaw describes it as an install-on-demand long-term memory plugin with auto-recall and capture, selected through plugins.slots.memory. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.
memory-wiki

URL: https://docs.openclaw.ai/plugins/memory-wiki

memory-wiki is not a replacement memory backend. It is a companion plugin that compiles durable memory into a navigable wiki with provenance, contradictions, dashboards, and wiki-native search and apply tools. That makes it more useful for knowledge maintenance than raw recall alone. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.
lossless-claw

URL: https://github.com/Martian-Engineering/lossless-claw

This is probably the most important community memory-context plugin right now. It replaces sliding-window compaction with DAG-based summarization that preserves full conversation history while keeping active context inside token limits. Popularity: about 4.3k GitHub stars.
memos-cloud

URL: https://github.com/MemTensor/MemOS-Cloud-OpenClaw-Plugin

MemOS Cloud is noteworthy because it treats memory as a lifecycle plugin, recalling context before execution and saving results after each run. That makes it closer to persistent memory infrastructure than a note store. Popularity: about 339 GitHub stars.

Model providers and harnesses

openai

URL: https://docs.openclaw.ai/providers/openai

The OpenAI provider remains useful mostly because OpenClaw separates direct API access via openai/* from ChatGPT or Codex OAuth via openai-codex/*, which avoids a lot of confusion around billing and runtime path. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.
anthropic

URL: https://docs.openclaw.ai/providers/anthropic

Anthropic is useful because OpenClaw supports both API keys and Claude CLI reuse, while still documenting API keys as the clearest long-lived gateway path. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.
openrouter

URL: https://docs.openclaw.ai/providers/openrouter

OpenRouter is the pragmatic aggregation plugin. It gives a single endpoint and API key for many models and defaults onboarding to openrouter/auto, which makes it operationally convenient even if it is not the most opinionated route. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.
google

URL: https://docs.openclaw.ai/providers/google

Google is more than just another text provider in OpenClaw. The plugin also brings image generation, media understanding, and web search via Gemini Grounding. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.
codex

URL: https://docs.openclaw.ai/plugins/codex-harness

The bundled Codex harness is useful when you want the Codex app-server to own the low-level session, thread resume, compaction, and execution path, while OpenClaw still owns channels and visible transcripts. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.

Dev workflows and observability

openclaw-codex-app-server

URL: https://github.com/pwrdrvr/openclaw-codex-app-server

This is one of the clearest community dev-workflow wins. It binds a chat to a Codex App Server thread and exposes chat-native controls for resume, planning, review, model selection, and compaction. Popularity: about 193 GitHub stars.
@opik/opik-openclaw

URL: https://github.com/comet-ml/opik-openclaw

Opik is the clean observability plugin pick. It exports LLM spans, tool spans, sub-agent spans, usage, and cost metadata to Opik, and it has visible release cadence and public docs. Popularity: about 453 to 459 GitHub stars.
manifest

URL: https://github.com/mnfst/manifest/tree/main/packages/openclaw-plugin

Manifest matters because it combines model routing and observability in one plugin, intercepting requests to score and route them while recording costs and timings. It is one of the bigger public projects in the ecosystem, though it has also had public friction around scanner warnings and onboarding noise. Popularity: about 4.3k GitHub stars.

Voice agents and multi-step workflows

voice-call

URL: https://docs.openclaw.ai/plugins/voice-call

This is the useful voice plugin, not the flashy one. It supports outbound calls, multi-turn conversations, inbound call policies, and current providers including Twilio, Telnyx, Plivo, and a mock transport. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.
webhooks

URL: https://docs.openclaw.ai/plugins/webhooks

The Webhooks plugin is the most underrated workflow plugin because it lets trusted systems such as Zapier, n8n, CI jobs, or internal services create and drive TaskFlows over authenticated HTTP routes. It is much less glamorous than AI orchestration marketing, but much closer to how teams actually automate work. Popularity: bundled first-party plugin, proxy metric 359k core repo stars.

Lead generation, CRM, and email-calendar automation

This is the part of the ecosystem where restraint is healthy. Based on the public packages and repositories I could verify, OpenClaw has promising native plugin experiments for Google Workspace and Google Calendar, and there are early CRM-oriented packages in the wider ecosystem, but the public popularity signals are still very small. tensorfold/openclaw-google-workspace presented an all-in-one Gmail, Calendar, Drive, Contacts, Tasks, and Sheets plugin but showed 0 GitHub stars. alefsolutions/openclaw-google-calendar also showed 0 GitHub stars. crm-skills-openclaw existed publicly with HubSpot and Salesforce direction, but it is a skill-oriented repo rather than a mature native plugin, and it showed about 1 GitHub star. That does not make these projects useless. It makes them early.

There is also an interesting social-and-growth plugin direction. SendIt exposes publishing, analytics, campaigns, inbox, CRM, and workflow tools through an OpenClaw plugin plus a bundled skill pack. Publicly, though, the repo still showed 0 GitHub stars at crawl time. The honest reading is that this category is promising, but not yet popular enough to call mature.

So the practical conclusion for lead generation and business automation is mildly unromantic. OpenClaw's strongest plugin-native wins today are still web access, memory, routing, channels, voice, and observability. For CRM-heavy or inbox-heavy workflows, the real-world path is still often a mix of Webhooks, a provider or browser plugin, and skills or API bridges rather than one dominant plugin package. That pattern is visible in the public ecosystem itself, and it maps directly to the plugin and skill stacks described in the OpenClaw production setup guide.

Bottom line

The useful OpenClaw plugin ecosystem today is less about novelty than about operational leverage. The boring picks are still the right picks: browser, firecrawl, tavily, memory-lancedb, memory-wiki, voice-call, webhooks, and the bundled provider plugins for OpenAI, Anthropic, Google, OpenRouter, and Codex. On the community side, lossless-claw, @opik/opik-openclaw, openclaw-codex-app-server, manifest, and wecom are the clearest public packages with visible utility and public traction.

When you later evaluate OpenClaw skills on the same registries, use the same hygiene as for plugins (pin versions, read manifests, treat scanning as directional). See the OpenClaw skills guide for per-role stacks and a security checklist. For extension directories, keep workspace plugin roots intentional and use allowlists when you cannot trust every path on disk.

The opinionated read is this. OpenClaw already has a serious native plugin platform, and extension directories give you predictable places to stage that code. Skills widen what you can publish without always widening what runs with full plugin privileges. The part that deserves trust right now is still the runtime plumbing layer for native plugins, not the long tail of business-ops demos. If you want a useful baseline rather than an aspirational one, that is the line to hold.

For how these plugin choices map to real user types and production workflows, see OpenClaw production setup patterns.

OpenClaw Skills Ecosystem and Practical Production Picks

Rost — Mon, 20 Apr 2026 09:51:37 +0000

OpenClaw has two extension stories, and they are easy to mix up.

Plugins extend the runtime. Skills extend the agent's behavior.

That distinction matters. A plugin adds a new capability surface such as a channel, provider, or tool integration. A skill is usually lighter. It teaches the agent how and when to use existing tools, binaries, APIs, or workflows. In practice, that makes skills the faster moving part of the OpenClaw ecosystem, and also the noisier one.

This article stays on the ecosystem and selection side. For how skills and plugins combine in practice by user type, see OpenClaw production setup patterns. The question here is simpler and more useful: which skills are actually worth installing, how do they fit into OpenClaw, and which ones look more like noise than durable tooling.

Popularity notes below use ClawHub stars and downloads as a rough snapshot on 2026-04-18.

What OpenClaw skills really are

The OpenClaw skill model is elegant because it is mostly plain files.

A typical skill looks like this:

my-skill/
  SKILL.md
  scripts/
  references/
  assets/

At minimum, the skill needs SKILL.md. That file contains YAML frontmatter and markdown instructions that tell the agent what the skill does, when to use it, and what tools or commands are available.

A minimal example looks like this:

---
name: hello_world
description: "A simple skill that says hello"
---

# Hello World Skill

Use this skill when the user wants a quick greeting.

The useful part is not the markdown itself. The useful part is how OpenClaw loads and gates skills.

A skill can be:

bundled with OpenClaw
installed into a workspace
shared at user level
scoped to an agent
injected by a plugin
filtered by OS, binaries, environment variables, or config

That last point is why OpenClaw skills feel closer to operational recipes than to prompt snippets. A good skill is not only descriptive. It declares enough metadata that OpenClaw can decide whether it should even be visible.

In other words, the system is more disciplined than the average public "prompt pack" marketplace.

OpenClaw skill locations and structure

OpenClaw uses a precedence model rather than a single global skills folder.

In practice, the highest value locations are:

<workspace>/skills for project specific overrides
<workspace>/.agents/skills for project agent skills
~/.agents/skills for personal agent skills
~/.openclaw/skills for shared local skills
bundled skills shipped with the install

That layout is one of the better design decisions in OpenClaw. It makes skills overrideable without editing the upstream install, and it keeps local customization from turning into a dirty fork.

It also means skill visibility and skill location are separate concerns.

A skill can exist locally and still be blocked from a given agent. That happens through skill allowlists in agents.defaults.skills and agents.list[].skills. For production, that separation is more important than the marketplace itself. It is what stops every agent from receiving every possible workflow.

There are also a few frontmatter flags worth remembering:

user-invocable exposes a slash command
disable-model-invocation keeps the skill out of the model prompt while still allowing explicit invocation
command-dispatch and command-tool can bypass model reasoning and call a tool directly
metadata.openclaw.requires.* can gate a skill on binaries, env vars, OS, or config

That is enough structure to make skills powerful, but also enough rope to create fragile packages if the metadata is sloppy.

Where to get OpenClaw skills

For practical use, there are three real sources.

ClawHub

ClawHub is the official public registry for OpenClaw skills and plugins. It is the default place to search, install, update, inspect versions, and see lightweight community signals such as stars and downloads.

If you only pick one source, use ClawHub.

Bundled skills

OpenClaw ships with bundled skills inside the install. These are lower friction, but the list is naturally smaller than the public registry.

Bundled skills are the closest thing the ecosystem has to a supported baseline.

Local and Git based skills

You can also keep skills in your own workspace or user folders, or pull them from public repositories.

This is useful for private skills, experiments, and local overrides.

There is also a public archived repository of registry skills on GitHub. It is useful as an audit trail, not as the first place to install from. Treat it as a historical dump and inspection surface, not as a curated store.

Community discovery layers such as awesome lists and filtered indexes are now part of the ecosystem as well. That is a signal in itself. Once a marketplace gets large enough, secondary curation becomes necessary.

How to install, update, and remove skills

The normal install flow is through the OpenClaw CLI.

Search

openclaw skills search "calendar"
openclaw skills search "github"
openclaw skills search --limit 20 --json

Install

openclaw skills install <skill-slug>
openclaw skills install <skill-slug> --version <version>
openclaw skills install <skill-slug> --force

By default, openclaw skills install places the skill into the active workspace skills/ directory.

Update

openclaw skills update <skill-slug>
openclaw skills update --all

Inspect and validate

openclaw skills list
openclaw skills list --eligible
openclaw skills info <name>
openclaw skills check

Install with the dedicated ClawHub CLI

If you publish skills, sync local folders, or want registry specific workflows, use the separate clawhub CLI.

npm i -g clawhub

clawhub search "research"
clawhub install <skill-slug>
clawhub update --all
clawhub skill publish ./my-skill --slug my-skill --name "My Skill" --version 1.0.0

The dedicated CLI writes a .clawhub/lock.json file in the working directory, which is useful for tracking what came from the registry.

Removal

This part is less polished than installation.

OpenClaw documents install and update flows for skills, but not a dedicated openclaw skills uninstall command. In practice, removal is filesystem based.

If a skill was installed into the workspace, remove its folder from <workspace>/skills, then start a new session.

If you want the skill to stay present but not be usable by a given agent, use skill allowlists instead of deletion.

That sounds a little manual because it is. The skill system is clean. The lifecycle UX is still catching up.

Maturity, reliability, community, and support

The skill system is mature enough to be real, but not mature enough to be calm.

That is the shortest honest summary.

What is mature

The underlying model is solid.

Skills are plain files, easy to inspect, easy to override, easy to version, and flexible enough to express both tiny instruction packs and fairly serious task helpers. OpenClaw also separates visibility, precedence, and runtime gating in a way that feels intentionally designed rather than bolted on.

The community signal is also real. OpenClaw itself is one of the most visible open source AI agent projects right now, and the skill ecosystem is large enough that third party curation has already appeared.

What is not mature

Registry quality is uneven.

The interesting issue is not whether a skill can work. Many do. The issue is whether the packaging, metadata, secret handling, and trust story are coherent.

A good OpenClaw skill is narrow, boring, and inspectable.

A weak OpenClaw skill usually has one or more of these problems:

metadata that does not match what the skill actually needs
hidden or undocumented environment variables
third party taps or installers with thin provenance
broad account access for a narrow task
hooks that quietly become default behavior
an impressive pitch with very little durable workflow value

This is why "most downloaded" is not the same thing as "production ready".

Support reality

Support comes from a mix of places:

official docs
ClawHub metadata and scan pages
GitHub issues and repository history
community comments and curation lists

That is enough for active operators. It is not the same as enterprise support.

If you need predictable ownership and response times, the skill ecosystem still feels more open source registry than platform contract.

Security concerns are not optional

OpenClaw is powerful because it can act.

That also means skills should be treated as code, not decoration.

The official security posture already hints at the correct mental model. Run the gateway on a dedicated machine, VM, or container. Use a dedicated OS user. Keep personal accounts and browser profiles away from that runtime. Restrict high risk tools. Treat links, attachments, and pasted instructions as hostile by default.

That guidance becomes more important, not less, once skills enter the picture.

The ClawHub moderation story has improved, but it is still fundamentally a public registry. Skills can be reported, hidden, deleted, and scanned. Publishing now has some basic controls. But the high level lesson from recent incidents is obvious: a public skill registry attracts malware quickly.

The right filter is simple:

instruction only skills are usually lower risk
small helper scripts can be fine if metadata and provenance are clean
hooks deserve extra scrutiny
skills that touch sensitive accounts need the highest bar
any scan flag should matter more than social hype

Popularity is not a trust signal. At best, it is a hint that a skill solved a real problem for many people.

The most useful OpenClaw skills right now

The most useful skills are not the flashiest ones. They are the ones that make repeated workflows cheaper, clearer, or safer.

My filter here is opinionated:

narrow scope beats broad promise
inspectable beats magical
local or transparent beats opaque proxying
workflow value beats novelty
clean packaging beats vibes

Safety and self correction

These are the least glamorous skills in the ecosystem, which is exactly why they matter.

Skill	URL	What it does	Why it is useful	Popularity	Scan note
self-improving-agent	https://clawhub.ai/pskoett/self-improving-agent	Captures learnings, errors, and corrections for future runs	One of the few skills that improves repeat work instead of adding another endpoint	3.2k stars, 396k downloads	benign
Skill Vetter 1.0.0	https://clawhub.ai/fedrov2025/skill-vetter-1-0-0	Reviews other skills for red flags before install	The skill ecosystem needed this very early, which says a lot about the ecosystem	9 stars, 7.3k downloads	benign

The first one is popular for a reason. It is not a gimmick. It creates a feedback loop around failure, which is one of the few things that consistently pays off in agent systems.

The second one is not popular in absolute terms, but it is one of the most sensible installs you can add if you plan to browse ClawHub regularly.

Search and research

Search skills are where OpenClaw gets genuinely useful, but also where packaging quality varies a lot.

Skill	URL	What it does	Why it is useful	Popularity	Scan note
Multi Search Engine	https://clawhub.ai/gpyangyoujun/multi-search-engine	Aggregates 16 search engines with operators and time filters	Better than single engine skills when you need broad recall	566 stars, 121k downloads	benign
Tavily Search	https://clawhub.ai/matthew77/liang-tavily-search	Tavily backed web search with snippets and metadata	Clean, narrow, and easy to reason about	92 stars, 36.2k downloads	benign
Academic Deep Research	https://clawhub.ai/kesslerio/academic-deep-research	Forces multi cycle research with explicit method	Good when you want structure, not just a quick answer	53 stars, 17.2k downloads	benign

The strongest pattern here is that method often beats breadth.

Multi Search Engine is the broad utility pick. Tavily Search is the cleaner service backed pick. Academic Deep Research is the process pick. None of them are flashy. All of them can be useful.

Developer workflows

This is the most obviously valuable category for technical readers.

Skill	URL	What it does	Why it is useful	Popularity	Scan note
Github	https://clawhub.ai/steipete/github	Uses the `gh` CLI for issues, PRs, runs, and API calls	One of the cleanest examples of a skill that maps directly to a real CLI	514 stars, 159k downloads	benign
Agent Browser	https://clawhub.ai/matrixy/agent-browser-clawdbot	Headless browser automation with snapshots and refs	Useful for tests, admin flows, and web tasks that are too awkward for plain fetch	323 stars, 90.1k downloads	benign
Opencode-controller	https://clawhub.ai/karatla/opencode-controller	Controls Opencode sessions, agents, and models	Practical if Opencode is already part of your workflow	72 stars, 17.9k downloads	benign

The GitHub skill is the kind of skill the ecosystem should have more of. It is boring, direct, and tied to a tool developers already know.

Agent Browser is more powerful, but also deserves more care. Browser state files, cookies, and page context are real data surfaces. That does not make the skill bad. It makes it operational.

Memory and knowledge

This category is more valuable than it looks at first glance.

Skill	URL	What it does	Why it is useful	Popularity	Scan note
ontology	https://clawhub.ai/oswalpalash/ontology	Typed knowledge graph for local structured memory	One of the strongest memory oriented skills I found	539 stars, 166k downloads	benign
Academic Deep Research	https://clawhub.ai/kesslerio/academic-deep-research	Research workflow with explicit evidence handling	Useful as a temporary method layer when memory quality matters	53 stars, 17.2k downloads	benign

The ontology skill stands out because it treats memory as structure rather than as note accumulation. That is a stronger long term direction for agent systems than endlessly appending summaries.

Workspace and personal productivity

This is the most uneven category. It contains genuinely useful skills, but also some of the most obvious metadata mismatches.

Skill	URL	What it does	Why it is useful	Popularity	Scan note
Gog	https://clawhub.ai/steipete/gog	Google Workspace CLI for Gmail, Calendar, Drive, Sheets, Docs	Very practical if your work already lives in Google Workspace	839 stars, 157k downloads	suspicious
Notion	https://clawhub.ai/steipete/notion	Notion API helper for pages, blocks, and databases	Useful in theory and often useful in practice, but packaging details matter	229 stars, 77.4k downloads	suspicious
Openai Whisper	https://clawhub.ai/steipete/openai-whisper	Local Whisper CLI transcription	One of the best examples of a narrow, useful local skill	274 stars, 70k downloads	benign

This is where the ecosystem gets interesting.

Gog is clearly useful. It is also a good example of why utility and trust are separate questions. The current scan notes point out metadata mismatches around binaries and credentials. That does not automatically make it malicious. It does make it a skill to inspect before granting account access.

Notion sits in the same category. Good workflow value. Messier packaging story.

Openai Whisper is the opposite. It is limited, local, and refreshingly straightforward.

The skills I would not rush to install

Some skills are popular for understandable reasons and still do not make my first pass list.

Skill	URL	Why I would wait	Popularity	Scan note
Desktop Control	https://clawhub.ai/matagul/desktop-control	Powerful enough to matter, but current scan status is a red flag and the capability is sensitive by design	299 stars, 47.7k downloads	suspicious
Baidu web search	https://clawhub.ai/ide-rea/baidu-search	Good idea, but undocumented env vars and metadata gaps are exactly the kind of sloppiness that should slow you down	203 stars, 79.2k downloads	suspicious
Obsidian	https://clawhub.ai/steipete/obsidian	High utility, but current scan notes call out mismatched metadata and undeclared file access	333 stars, 82.5k downloads	suspicious

That is the larger pattern in one table.

High download counts do not erase packaging problems.

The real shape of the OpenClaw skills ecosystem

The OpenClaw skills ecosystem is already big enough to be useful and already noisy enough to need curation.

That is usually the moment an ecosystem becomes real.

The good news is that the underlying skill format is strong. Skills are inspectable. Overrides are clean. Precedence is sensible. Gating is practical. ClawHub provides versioning, discovery, stars, downloads, comments, and basic moderation.

The bad news is that public registries move faster than trust models.

If you want the short opinionated take, it is this:

the skill system is better than the average AI marketplace
the registry is more useful than safe by default
the best skills are small, specific, and operationally boring
suspicious metadata is not a cosmetic issue
"popular" should never outrank "inspectable"

Final take

If I were trimming OpenClaw skills down to the set that looks most durable right now, I would start with:

self-improving-agent
Skill Vetter
Github
Multi Search Engine
Tavily Search
Academic Deep Research
ontology
Openai Whisper

Then I would consider Gog and Notion only after a manual review of current metadata, source, and secret handling.

That is probably the right framing for the entire OpenClaw skills ecosystem in 2026.

The good part is already very good.

The safe part still requires an adult in the room.

For how skills combine with plugins in real deployments by user type, see OpenClaw production setup patterns.

For the plugin layer those skills depend on, see OpenClaw plugins guide.

OpenClaw Production Setup Patterns with Plugins and Skills

Rost — Mon, 20 Apr 2026 09:51:33 +0000

OpenClaw looks simple in demos.
In production, it becomes a system.

The real complexity is not in prompts or models. It is in how plugins and skills interact to manage state, integrate systems, and execute workflows over time.

A useful mental model:

Plugins = capabilities

APIs, memory, tools, integrations
Skills = behavior

How the agent uses those capabilities in structured ways

Production systems fail when these two are mixed without boundaries.

They become reliable when both are mapped to real user needs.

How to think about production setup

Most teams ask what plugins or skills they should install.

That is the wrong starting point.

A better question is:

Who is this system for, and what work are they trying to complete?

Each user type creates a different architecture:

developers need control and traceability
automation users need triggers and determinism
researchers need memory and retrieval
support teams need continuity and communication
growth teams need pipelines and data flow

Plugins enable these systems.

Skills make them usable.

The combination of both, tailored to a real user profile, is what separates a production system from a demo.

Installation and lifecycle note

This article focuses on architecture patterns and user-specific configurations.

For full installation and lifecycle details see:

OpenClaw plugins guide — plugin installation, extension directories, CLI lifecycle, and mature picks
OpenClaw skills guide — ClawHub discovery, install and removal flows, security tradeoffs, and per-role stacks
OpenClaw quickstart — Docker-based installation with Ollama GPU or Claude

In production, both plugins and skills should be treated as dependencies with version control, review, and rollback strategies.

1. The Developer Workflow User

Profile

This user treats OpenClaw as an execution layer for development workflows.

Not just code generation, but:

debugging
iteration
multi-step reasoning
repository interaction

The system is expected to remember decisions, track changes, and make its reasoning visible.

Core needs

The key requirement is continuity and visibility.

Developers need to understand:

what the system did
why it did it
how to reproduce or fix it

Without structured memory, every session starts from scratch. Without observability, failures are invisible and expensive to diagnose.

Typical OpenClaw Plugin Set

model providers

openai, anthropic, openrouter for fallback routing
memory and context

memory lancedb, lossless claw
dev workflow

codex app server, codex harness
observability

opik openclaw, manifest

Why this helps

Plugins transform OpenClaw into a controlled execution environment.

Memory lancedb and lossless claw preserve intent across iterations, so the system does not reset its understanding every few turns. Lossless context plugins are especially valuable here because they preserve intent rather than raw tokens.

Codex plugins move the agent from passive assistant to active participant. They enable real execution, validation, and iteration on code rather than static responses.

Observability completes the picture. It answers what happened, which is often more important than the output itself. Without this layer, the system feels intelligent but remains unreliable in practice.

Typical OpenClaw Skill Set

Skill	Link	Why it helps
github	clawhub.ai/steipete/github	Best day-to-day control plane for issues, PRs, CI status, and `gh` API queries. Instruction-only and low risk. 517 stars, 159k downloads.
tmux	clawhub.ai/steipete/tmux	Keeps long-running builds, test servers, and agent-driven shells from collapsing into one fragile terminal. 38 stars, 22.5k downloads.
session-logs	clawhub.ai/guogang1024/session-logs	Turns prior agent sessions into searchable operational memory. Answers "what did the agent actually do yesterday". 22 stars, 30.9k downloads.
model-usage	clawhub.ai/steipete/model-usage	Local model cost breakdowns by model rather than a vague monthly bill. 101 stars, 32k downloads.
nano-pdf	clawhub.ai/steipete/nano-pdf	Handles release notes, partner decks, and PDF patching without context switching. 220 stars, 91.5k downloads.
openclaw-token-optimizer	clawhub.ai/asif2bd/openclaw-token-optimizer	Workspace-level token and cost hygiene when usage creeps up from overpowered defaults. 28 stars, 9.4k downloads.
openclaw-skill-vetter	clawhub.ai/donovanpankratz-del/openclaw-skill-vetter	Pre-install review checklist for suspicious community skills and risky bundles. 24 stars, 17.4k downloads.

Why this helps

Skills define how developers actually work with the system.

github skill enables real repository workflows instead of manual copy-paste
tmux allows long-running or parallel agent tasks without session loss
session-logs provide operational memory beyond the chat window
model-usage and token-optimizer expose cost and performance patterns
skill-vetter adds package-review discipline before any community install

Plugins give capability. Skills turn that into repeatable engineering workflows.

How plugins and skills together serve the developer

The plugin layer provides the raw infrastructure: persistent memory, code execution, and observability.

The skill layer structures how a developer actually interacts with that infrastructure day to day.

A developer with codex plugins but no github skill has execution power without workflow integration. A developer with session-logs but no memory plugin has audit trails without cross-session context.

The combination is what makes the system feel like a reliable collaborator rather than an unpredictable assistant.

For more on skill selection and security review for this profile see the OpenClaw skills guide.

OpenClaw Skill and Plugin Install for Developer Workflow

# Plugins — capabilities layer
openclaw plugins install memory-lancedb             # persistent long-term memory with vector recall
openclaw plugins install lossless-claw              # lossless context compression, preserves intent not tokens
openclaw plugins install openclaw-codex-app-server  # code execution harness, resume, planning, and model selection
openclaw plugins install @opik/opik-openclaw        # LLM observability: spans, tool calls, usage, and cost

# Skills — behavior layer
openclaw skills install github                      # PR, issue, CI status, and gh API workflows
openclaw skills install tmux                        # persistent terminal sessions for long-running tasks
openclaw skills install session-logs                # searchable agent session history across days
openclaw skills install model-usage                 # per-model cost breakdown from session logs
openclaw skills install nano-pdf                    # PDF editing, patching, and release note handling
openclaw skills install openclaw-token-optimizer    # workspace-level token and cost hygiene
openclaw skills install openclaw-skill-vetter       # pre-install review checklist before adding community skills

2. The Automation and Ops User

Profile

This user is not chatting. They are orchestrating.

workflows
triggers
pipelines
system integrations

For this profile, OpenClaw becomes part of infrastructure, not a UI. The system is expected to react to events and coordinate workflows across systems without human intervention at each step.

Core needs

deterministic execution
external triggers
reliability under failure
integration with existing systems

The focus shifts from intelligence to predictability. Automation workflows must be repeatable, externally triggered, and easy to integrate into existing infrastructure.

Typical OpenClaw Plugin Set

workflow and triggers

webhooks
tools

browser, firecrawl, exa
providers

openrouter or google for resilience
integrations

lightweight API wrappers, not monolithic plugins

Why this helps

Webhooks act as controlled entry points into the system, turning external events into structured execution.

Search and scraping tools provide flexibility when APIs are unavailable or inconsistent. Exa and firecrawl handle different retrieval patterns and are worth using together.

Provider routing reduces dependency on a single model, improving resilience under failure conditions. Integrations are best handled through lightweight API wrappers rather than single all-in-one packages, which keeps failure surfaces small and debugging straightforward.

The system stops being reactive chat and becomes a component in a larger automation pipeline.

Typical OpenClaw Skill Set

Skill	Link	Why it helps
taskflow	bundled official skill	Durable multi-step execution with one owner context across detached tasks. The right abstraction when work spans sessions.
taskflow-inbox-triage	bundled official skill	Concrete pattern for routing inbound work by intent and urgency. Good fit for event-driven pipelines.
tmux	clawhub.ai/steipete/tmux	Necessary when detached tasks become long-running or require interactive shell sessions.
session-logs	clawhub.ai/guogang1024/session-logs	Postmortems are easier when logs are first-class rather than an afterthought.
blogwatcher	clawhub.ai/steipete/blogwatcher	Practical for monitoring release feeds, vendor blogs, and changelogs without loading a full scraping stack.
github	clawhub.ai/steipete/github	Incident and release work is often GitHub work. Keeps CI and issue workflows close to the operator.

Why this helps

Automation without structure breaks quickly.

taskflow introduces multi-step execution ownership across detached sessions
inbox triage provides a repeatable pattern for routing work by intent and urgency
tmux enables persistent execution contexts for long-running tasks
session-logs support debugging, auditability, and postmortems
blogwatcher handles passive monitoring without a full scraping stack

Skills provide structure where plugins only provide access.

How plugins and skills together serve the automation user

The plugin layer connects OpenClaw to the external world: webhooks bring in events, tools provide flexible data access, provider routing adds resilience.

The skill layer gives that access structure: taskflow ensures multi-step work maintains ownership and context, triage patterns route incoming work predictably, and logs make failures diagnosable after the fact.

An ops setup with webhooks but no taskflow skill has triggers but no consistent execution model. A taskflow-based system without provider routing has structure but a single point of failure.

Together, they make OpenClaw a reliable component in a larger automation pipeline rather than a reactive chat interface.

OpenClaw Skill and Plugin Install for Automation and Ops

# Plugins — capabilities layer
openclaw plugins install webhooks    # external event triggers over authenticated HTTP routes
openclaw plugins install browser     # managed browser profile for dynamic page interaction
openclaw plugins install firecrawl   # structured extraction from static and JS-heavy content
openclaw plugins install exa         # hybrid search and extraction in one provider

# Skills — behavior layer
# taskflow and taskflow-inbox-triage are bundled — enable via agent config:
# agents.defaults.skills: ["taskflow", "taskflow-inbox-triage"]

openclaw skills install tmux         # persistent shell sessions for long-running detached tasks
openclaw skills install session-logs # postmortem and audit trail for agent actions
openclaw skills install blogwatcher  # monitor release feeds and vendor changelogs without a full scraper
openclaw skills install github       # CI, incident, and release workflows from the agent surface

3. The Knowledge and Research User

Profile

This user builds knowledge over time.

research
synthesis
documentation
analysis

The goal is not to execute tasks but to collect, organise, and reuse information across sessions and projects. The system must remember what it has learned and retrieve it accurately.

Core needs

persistent memory
high quality retrieval
traceability
consistency

Reliability in this context is less about speed and more about correctness and repeatability. The system should build on prior work rather than repeat the same research each session.

Typical OpenClaw Plugin Set

memory

memory lancedb, memory wiki
search

tavily, exa, firecrawl
providers

anthropic or google for large context windows

Why this helps

Memory plugins turn transient interactions into persistent knowledge. Lancedb provides vector-based retrieval, while wiki-style memory adds structure and traceability so users can verify where information came from.

Search tools improve input quality, which directly impacts output quality. Tavily and exa provide different retrieval characteristics and are worth using together for research coverage.

Larger context providers like Anthropic or Google are relevant here because synthesis often requires holding more source material at once than a standard context window allows.

Without strong memory plugins, research becomes repetitive regardless of how well the skills are configured.

Typical OpenClaw Skill Set

Skill	Link	Why it helps
multi-search-engine	clawhub.ai/gpyangyoujun/multi-search-engine	Cross-engine query aggregation with useful operators and time filters. 566 stars, 121k downloads.
agent-browser	clawhub.ai/matrixy/agent-browser-clawdbot	Controlled interaction with dynamic pages. Better fit for research than random scraping wrappers. 323 stars, 90.2k downloads.
blogwatcher	clawhub.ai/steipete/blogwatcher	Keeps a research corpus fresh through RSS and blog feeds instead of repeated manual browsing. 57 stars, 34.9k downloads.
nano-pdf	clawhub.ai/steipete/nano-pdf	PDF edits, redlines, or document cleanup without switching to a separate tool. 220 stars, 91.5k downloads.
openai-whisper	clawhub.ai/steipete/openai-whisper	Local speech-to-text for interview recordings, meeting audio, and field notes. 274 stars, 70.1k downloads.
notion	clawhub.ai/steipete/notion	Structured team knowledge base for pages and databases. Review secret handling before install. 230 stars, 77.4k downloads.
obsidian	clawhub.ai/steipete/obsidian	Local markdown vault automation for personal knowledge management. High value, review install source. 333 stars, 82.5k downloads.

Why this helps

Skills define how research actually happens.

multi-search-engine improves discovery quality across sources simultaneously
agent-browser enables controlled interaction with real web content
blogwatcher maintains fresh information streams automatically
pdf and whisper handle real-world data formats that arrive outside clean APIs
notion and obsidian structure outputs into persistent, queryable knowledge systems

The system evolves from a query engine into a knowledge engine.

How plugins and skills together serve the research user

The plugin layer ensures the system remembers and retrieves reliably: lancedb builds a persistent vector store, wiki memory adds provenance, and search plugins expand the input surface.

The skill layer determines how research actually flows: multi-search drives discovery, agent-browser handles dynamic sources, blogwatcher maintains ongoing monitoring, and note-taking skills capture outputs into usable formats.

Without the memory plugin layer, even excellent skills produce knowledge that evaporates after each session. Without the skill layer, even a well-configured memory system sits idle because there is no structured process to feed it.

See the OpenClaw plugins guide for memory plugin selection and configuration details.

OpenClaw Skill and Plugin Install for Knowledge and Research

# Plugins — capabilities layer
openclaw plugins install memory-lancedb   # persistent vector memory with auto-recall and capture
openclaw plugins install memory-wiki      # structured wiki layer with provenance and contradiction tracking
openclaw plugins install tavily           # LLM-optimized structured search and extraction
openclaw plugins install exa              # hybrid search modes plus extraction in one provider
openclaw plugins install firecrawl        # web_search provider and fallback fetch for JS-heavy pages

# Skills — behavior layer
openclaw skills install multi-search-engine    # 16-engine aggregation with operators and time filters
openclaw skills install agent-browser-clawdbot # controlled browser interaction for dynamic pages
openclaw skills install blogwatcher            # RSS and blog feed monitoring to keep corpus fresh
openclaw skills install nano-pdf               # PDF editing, redlines, and document cleanup
openclaw skills install openai-whisper         # local speech-to-text for recordings and meeting audio
openclaw skills install notion                 # structured team knowledge base (review secret handling first)
# openclaw skills install obsidian             # local markdown vault — review install source before enabling

4. The Customer Support and Communication User

Profile

This user operates across communication channels.

customer support
internal communication
ticket handling

The challenge is not generating answers but maintaining context across conversations and platforms.

Core needs

context continuity across conversations
multi-channel integration
fast response generation
auditability

Typical OpenClaw Plugin Set

communication channels

msteams, matrix, wecom, discourse
memory

memory lancedb
tools

browser

Why this helps

Channel plugins embed OpenClaw into existing workflows instead of requiring users to switch environments. Where communication happens determines which plugins matter most.

Memory ensures conversations do not reset between sessions, which is essential for support scenarios where context accumulates over time. A support system without persistent memory forces operators to re-establish context on every interaction.

Browser access allows the system to retrieve up-to-date information without relying on static integrations — useful when product documentation or policies change frequently.

Typical OpenClaw Skill Set

Skill	Link	Why it helps
himalaya	clawhub.ai/lamelas/himalaya	Terminal email with triage, reply, forward, search, and organization. One of the cleaner communication skills in the ecosystem. 62 stars, 38.3k downloads.
slack	clawhub.ai/steipete/slack	Useful when support work lives in Slack. Review undeclared token assumptions before install. 117 stars, 39.1k downloads.
session-logs	clawhub.ai/guogang1024/session-logs	Critical for reconstructing prior support interactions and agent decisions. 22 stars, 30.9k downloads.
nano-pdf	clawhub.ai/steipete/nano-pdf	Essential when customers send forms, guides, or documents needing quick cleanup or annotation.
openai-whisper	clawhub.ai/steipete/openai-whisper	Local speech-to-text for voicemail, support calls, or short media handoffs.
taskflow-inbox-triage	bundled official skill	Workflow pattern for immediate reply, delayed follow-up, and later summary queues.
notion	clawhub.ai/steipete/notion	Triage notes, FAQ capture, and evolving support playbooks. Fix secret handling before use.

Why this helps

Support workflows are repetitive, structured, and high-stakes.

himalaya and slack enable direct interaction across the channels where support happens
session-logs provide the audit trail for prior interactions and agent decisions
inbox triage structures incoming requests into actionable queues
whisper and pdf handle real customer inputs that arrive in non-text formats
notion captures evolving support knowledge into reusable playbooks

Skills reduce cognitive load and standardize response patterns.

How plugins and skills together serve the support user

The plugin layer connects OpenClaw to the channels where support actually happens: msteams, matrix, or discourse for channel presence, lancedb for context persistence, browser for live information retrieval.

The skill layer structures how each interaction is handled: himalaya and slack bring communication directly to the agent surface, inbox triage routes work by urgency, session-logs maintain the audit trail, and notion captures institutional knowledge.

Support operators touch more customer data than most other roles. That makes the combination of narrow skill sets, per-agent allowlists, and strong auditability especially important. The stack should be smaller than a research stack by design.

See the OpenClaw skills guide for security guidance on communication skills and per-agent allowlist configuration.

OpenClaw Skill and Plugin Install for Customer Support and Communication

# Plugins — capabilities layer
# Choose the channel plugin that matches your platform:
openclaw plugins install msteams   # Microsoft Teams: Azure Bot, tenant credentials, group chat policies
# openclaw plugins install matrix  # Matrix: DMs, rooms, threads, media, E2EE
# openclaw plugins install wecom   # WeCom: direct messages, group chats, Bot and Agent modes

openclaw plugins install memory-lancedb   # persistent conversation context across sessions
openclaw plugins install browser          # live information retrieval when docs or policies change

# Skills — behavior layer
# taskflow-inbox-triage is bundled — enable per agent via config:
# agents.list[].skills: ["taskflow-inbox-triage", "himalaya", "session-logs"]

openclaw skills install himalaya       # terminal email with triage, reply, forward, and search
openclaw skills install session-logs   # audit trail for prior interactions and agent decisions
openclaw skills install nano-pdf       # handle forms, guides, and documents from customers
openclaw skills install openai-whisper # local speech-to-text for voicemail and support calls
# openclaw skills install notion       # triage notes and support playbooks (review secret handling first)
# openclaw skills install slack        # Slack channel integration (review token assumptions before enabling)

5. The Growth and Lead Generation User

Profile

This user builds pipelines.

lead discovery
enrichment
outreach preparation

Core needs

data collection from public sources
enrichment and signal extraction
integration with CRM systems
repeatability across campaigns

Typical OpenClaw Plugin Set

tools

browser, firecrawl
workflow

webhooks
integrations

CRM APIs or early-stage connector plugins
providers

openrouter for cost-efficient routing

Why this helps

Browser and firecrawl handle different source types and are worth using together — browser for dynamic interactive pages, firecrawl for structured extraction from static content.

Webhooks push enriched results into downstream systems such as CRMs or analytics pipelines. Provider routing through openrouter keeps costs predictable when running repeated enrichment passes over large datasets.

Many growth-focused plugins still show maturity gaps in the ecosystem. Treat them as processing layers rather than systems of record, and verify stability before relying on them in production pipelines.

Typical OpenClaw Skill Set

Skill	Link	Why it helps
xurl	clawhub.ai/gaurangzalariya/xurl	Converts public X content into pain points, messaging angles, and lead themes without a heavy API-driven setup. 7 stars, 10.2k downloads.
multi-search-engine	clawhub.ai/gpyangyoujun/multi-search-engine	Broad prospect and market discovery when one engine never tells the full story. 566 stars, 121k downloads.
agent-browser	clawhub.ai/matrixy/agent-browser-clawdbot	Controlled interaction with dynamic prospect pages, forms, or dashboards. 323 stars, 90.2k downloads.
blogwatcher	clawhub.ai/steipete/blogwatcher	Monitors competitor posts, launch feeds, and niche sites for ongoing market signals. 57 stars, 34.9k downloads.
notion	clawhub.ai/steipete/notion	Turns captured signals into structured campaign or pipeline notes. Review secret handling before use.
openai-whisper	clawhub.ai/steipete/openai-whisper	Handy for call snippets, voice notes, and quick post-meeting debrief capture.
slack	clawhub.ai/steipete/slack	Useful for sharing SDR notes and campaign updates. Review token scope before enabling.

Why this helps

Growth workflows rely on signal extraction from public sources.

xurl extracts themes and pain points from social content without a heavy API setup
multi-search and agent-browser provide broad and deep discovery across sources
blogwatcher tracks ongoing market signals and competitor activity
notion structures raw signal into actionable pipeline assets
whisper captures voice-based research inputs

Skills transform scattered public data into repeatable outreach inputs.

How plugins and skills together serve the growth user

The plugin layer provides data infrastructure: browser and firecrawl gather raw web data, webhooks push enriched results downstream, and openrouter manages cost across repeated enrichment runs.

The skill layer extracts signal and structures it: xurl surfaces social themes, multi-search broadens discovery coverage, blogwatcher maintains continuous monitoring, and notion converts raw captures into organized pipeline assets.

Growth setups have a natural tendency toward over-engineering. The most stable configurations stay public-facing and avoid installing every scraping wrapper that promises infinite automation. A focused stack with clear data flow is more durable than an ambitious one that requires constant maintenance.

OpenClaw Skill and Plugin Install for Growth and Lead Generation

# Plugins — capabilities layer
openclaw plugins install browser     # dynamic page interaction for prospect research and forms
openclaw plugins install firecrawl   # structured content extraction from static sources
openclaw plugins install webhooks    # push enriched results to CRM and analytics downstream

# Skills — behavior layer
openclaw skills install xurl                   # extract pain points and messaging angles from public X content
openclaw skills install multi-search-engine    # multi-engine prospect and market discovery
openclaw skills install agent-browser-clawdbot # controlled interaction with dynamic pages and dashboards
openclaw skills install blogwatcher            # monitor competitor posts, launch feeds, and niche sites
openclaw skills install notion                 # structure captured signals into campaign pipeline notes (review secret handling first)
openclaw skills install openai-whisper         # capture call snippets and voice debrief notes locally
# openclaw skills install slack                # share SDR notes and updates (review token scope before enabling)

Cross-cutting production patterns

Separation of responsibilities

Plugins and skills should not overlap.

plugins provide capabilities
skills define behavior

Mixing them leads to unpredictable systems where failures are difficult to attribute. When something breaks, you should be able to say immediately whether it is a capability problem or a behavior problem.

Start from user intent, not feature lists

Configuration should emerge from what a user actually does, not from what looks impressive.

Two systems with identical plugins can behave completely differently depending on which skills are loaded and for which agent roles. The skill layer is the real interface.

Minimalism wins

More plugins do not mean better systems.

Production setups converge toward:

fewer components
clearer ownership
predictable behavior

Adding a component should require justifying what breaks if it is removed. The most effective setups are not the most complex ones.

Observability is not optional

Without logs and visibility:

failures are silent
debugging is slow
trust erodes

The session-logs skill and observability plugins like opik openclaw are cheap insurance against invisible failures. They belong in every production setup regardless of user type.

Per-agent allowlists matter

OpenClaw's agents.list[].skills configuration replaces inherited defaults entirely for a given agent role.

That is the right tool for high-consequence roles like support or finance operators where a narrow, explicit skill set is safer than a broad inherited one.

Third-party components need review

Skills from ClawHub should be inspected before install.

Run clawhub inspect <slug> to check scan results, declared binaries, and credential use before enabling any community skill in production. Instruction-only skills are safer than code-bearing ones. Bundled official skills are the safest starting point.

The OpenClaw skills guide covers the full review workflow and security checklist.

Final thoughts

OpenClaw production systems are not built by installing everything available.

They are shaped by:

user intent
workflow structure
clear separation between capability and behavior

Plugins make the system powerful.

Skills make it usable.

The most effective setups are the ones where every component has a clear reason to exist, and every user type has both the capabilities and the structured behaviors needed to do their actual work.

For next steps:

OpenClaw plugins guide — plugin lifecycle, ecosystem picks, and safety rails
OpenClaw skills guide — ClawHub discovery, per-role stacks, and security tradeoffs
OpenClaw quickstart — installation with Docker

Hermes AI Assistant Skills for Real Production Setups

Rost — Mon, 20 Apr 2026 09:50:09 +0000

Hermes AI assistant, officially documented as Hermes Agent, is not positioned as a simple chat wrapper.

For installation, provider setup, tool sandboxing, and gateway configuration, see the Hermes AI Assistant guide. This article focuses on the skills and profile architecture that determines how Hermes behaves once it is running.

The official docs and repository describe a self-improving agent with a built-in learning loop that creates skills from experience, improves them during use, persists knowledge across sessions, and runs on anything from a low-cost VPS to cloud sandboxes.

In April, 2026, the public GitHub repository shows about 94.6k stars, 13.2k forks, and a latest release tagged v0.10.0 on April 16, 2026. That is enough activity to call the project fast-moving, well-adopted, and still operationally young at the same time.

That dual nature matters for production design. Hermes is mature enough to support real work, but dynamic enough that a messy setup will age badly. The article below treats configuration and skills as an operational architecture question, not as a feature checklist.

Why Hermes needs a profile-first architecture

Hermes skills are on-demand knowledge documents. They use progressive disclosure so the agent can see a compact skill index first and only load full skill content when needed, which keeps token use under control even when many skills are installed. Every installed skill becomes a slash command in the CLI and in messaging surfaces, and the docs explicitly position skills as the preferred extension mechanism when a capability can be expressed with instructions, shell commands, and existing tools rather than custom agent code.

The production complication is that Hermes treats skills as living state, not frozen packages. Bundled skills, hub-installed skills, and agent-created skills all live under ~/.hermes/skills/, and the docs state that the agent can modify or delete skills. The same system exposes create, patch, edit, delete, and supporting-file actions for skill management. That is powerful, but it also means one oversized "do everything" agent tends to become a procedural junk drawer.

Profiles are the answer. Hermes profiles are fully isolated environments, each with its own config.yaml, .env, SOUL.md, memories, sessions, skills, cron jobs, and state database. The CLI also turns a profile into its own command alias, so a profile called coder becomes coder chat, coder setup, coder gateway start, and so on. In practice, that makes profiles the real unit of production ownership, not the individual skill.

The production baseline

The baseline shape is surprisingly clean. Hermes stores non-secret behavior in ~/.hermes/config.yaml, secrets in ~/.hermes/.env, identity in SOUL.md, persistent facts in memories/, procedural knowledge in skills/, scheduled jobs in cron/, sessions in sessions/, and logs in logs/. The hermes config set command routes API keys into .env and everything else into config.yaml, and the documented precedence order is CLI flags first, then config.yaml, then .env, then built-in defaults. That is also the cleanest answer to the production FAQ about how secrets and config should be split.

A practical multi-profile layout usually ends up looking something like this, with one profile per responsibility rather than one profile per human:

~/.hermes/profiles/
  eng/
  research/
  ops/
  execops/
  ml/

That pattern matches how Hermes profiles are documented: each profile is its own isolated environment, and profiles can be cloned from a base configuration when common defaults are useful. The docs also note that profiles do not share memory or sessions, and that updated skills can be synced across profiles when the main installation is updated.

The next production boundary is execution. Hermes supports six terminal backends - local, Docker, SSH, Modal, Daytona, and Singularity - and the security docs describe a defense-in-depth model that includes dangerous command approval, container isolation, MCP credential filtering, context file scanning, cross-session isolation, and input sanitization. In other words, the "profile first" decision answers who owns state, and the backend decision answers where risky work is allowed to happen.

Automation sits on top of that baseline. Hermes cron jobs can attach zero, one, or multiple skills, and they run in fresh agent sessions rather than inheriting the current chat. The messaging gateway is also the background process that manages sessions, runs cron, and routes results back to platforms like Telegram, Discord, Slack, WhatsApp, Email, Matrix, and others. The official MCP guide adds one more production rule that is easy to overlook: the best pattern is not to connect everything, but to expose the smallest useful surface.

The software engineering profile

The most obvious Hermes persona is the software engineer who wants the agent to behave less like a chat window and more like a repeatable repo operator. This profile usually cares about repository auth, issue triage, PR creation, code review, debugging, and plan-backed execution. In the Hermes catalogs, the core built-in skill pack is unusually coherent for that job: github-auth, github-issues, github-pr-workflow, github-code-review, code-review, plan, writing-plans, systematic-debugging, and test-driven-development. If delegation matters, Hermes also ships built-in autonomous agent skills such as codex, claude-code, opencode, and hermes-agent-spawning.

What makes that pack useful is not any single skill. It is the way the skills encode development procedure. github-pr-workflow covers the full PR lifecycle, github-issues formalizes issue operations, github-code-review and code-review make review a distinct step instead of an afterthought, and systematic-debugging keeps the agent from jumping straight to premature fixes. That also answers the practical question of which AI assistant skills matter most for coding workflows. The highest-value skills are usually the ones that lock in repo hygiene and review discipline, not the ones that promise more raw code generation.

Hermes delegation strengthens this profile further. The platform can spawn isolated child agents with their own conversation, terminal session, and toolset, and only the final summary is returned to the parent. For codebases, that is a cleaner fit than stuffing every intermediate diff, stack trace, and review note into one conversation. In production terms, the engineering profile benefits from narrow skill sets, a sandboxed backend such as Docker or SSH, and generous use of delegation when context noise starts to dominate.

The research and knowledge profile

The research profile is where Hermes starts to feel distinct from ordinary assistants. The built-in catalogs already include arxiv, duckduckgo-search, blogwatcher, llm-wiki, ocr-and-documents, obsidian, domain-intel, and ml-paper-writing, while the official optional catalog adds qmd, parallel-cli, scrapling, and a broader research tier for specialized domains. That stack covers paper search, source monitoring, OCR, local note systems, domain reconnaissance, writing, and hybrid retrieval without forcing everything into a single RAG pattern.

This profile is also the clearest place to answer the memory-versus-skills question. Hermes documentation defines memory as facts about users, projects, and preferences, while skills store procedures for how to do things. Research work needs both. Memory holds what the assistant has already learned about the domain and the reader's preferences; skills encode repeatable procedures such as "scan arXiv, summarize new papers, and write notes into Obsidian." That distinction matters because production research systems fail when everything is treated as memory or everything is treated as workflow. Hermes gives those concerns separate homes.

The research profile also benefits disproportionately from cron. Hermes cron jobs can explicitly load skills before execution, and the automation guides stress that scheduled prompts must be fully self-contained because they run in fresh sessions. A recurring pipeline that combines blogwatcher, arxiv, obsidian, or llm-wiki is therefore more reliable than a vague "check what changed today" job. In other words, research profiles work best when source discovery, note writing, and long-term storage are each represented by a named skill rather than hidden inside one long natural-language prompt.

The automation and operations profile

The ops profile is less glamorous and often more valuable. This is the user who wants Hermes to react to events, inspect systems, run scripted checks, route output to a channel, and do all of that without turning the host into a liability. Hermes has the right building blocks for that style of work: built-in webhook-subscriptions for event-driven activation, built-in native-mcp and mcporter for MCP-based tools, and official optional skills such as docker-management, fastmcp, cli, and 1password when the workflow expands into containers, custom MCP servers, or secret injection.

The reason this pack works is that each skill owns one boundary. webhook-subscriptions handles ingress from external systems. docker-management turns container chores into a named procedure instead of a free-form shell game. fastmcp is useful when Hermes needs to become the orchestrator around new MCP tools, and 1password keeps secret handling explicit rather than smuggled into shell history or markdown files. The official MCP guidance reinforces the same production instinct: connect the right thing with the smallest useful surface.

This profile is also the cleanest place to answer how scheduled AI workflows stay reliable. Hermes cron documentation says jobs run in fresh sessions, can attach one or more skills, and should use self-contained prompts. The cron troubleshooting guide adds that automatic firing depends on the gateway ticker rather than an ordinary CLI chat session. So the reliable pattern is straightforward even if the implementation is not: explicit skills, explicit delivery target, self-contained prompt, isolated backend, and a gateway that is actually running.

The executive operations profile

There is a quieter but very real Hermes persona that looks like a chief of staff, operations lead, or heavily overloaded founder. The relevant skills are less flashy and more office-shaped: google-workspace, notion, linear, nano-pdf, powerpoint, and the built-in himalaya email skill, plus official optional skills such as agentmail, telephony, and one-three-one-rule. That mix gives Hermes access to inbox, calendar, docs, tasks, decks, PDF cleanup, a structured communication framework, and even phone and SMS workflows where that actually matters.

The flow here is more important than the catalog. google-workspace anchors day-to-day execution. Notion and Linear prevent the assistant from becoming the task system of record. one-three-one-rule is surprisingly useful because decision support is often the hardest thing to standardize, and that skill gives Hermes a named procedure for proposals rather than generic "summarize this" behavior. nano-pdf and powerpoint are the kind of operational multipliers that look small until a team starts touching decks and PDFs every day.

Hermes messaging and voice features make this profile more practical than it first appears. The gateway can expose the agent through Slack, Telegram, Discord, WhatsApp, Email, Matrix, and several other channels, and the voice stack supports microphone input, spoken replies in messaging, and live Discord voice conversations. The docs also note that one Hermes instance can serve multiple users through allowlists and DM pairing, while bot tokens remain exclusive to a single profile. That is why a communication-heavy deployment usually benefits from at least one dedicated profile instead of sharing the same bot identity with engineering or ops.

The ML and data platform profile

Hermes is built by a research lab, and that lineage shows. The catalogs include jupyter-live-kernel for stateful notebook-style work, huggingface-hub for model and dataset operations, evaluating-llms-harness and weights-and-biases for evaluation and experiment tracking, qdrant-vector-search for production RAG storage, and a large built-in and optional MLOps tier with skills such as axolotl, fine-tuning-with-trl, modal-serverless-gpu, lambda-labs-gpu-cloud, flash-attention, tensorrt-llm, pinecone, qdrant, and nemo-curator.

What is notable here is not just breadth. It is that the skills span the whole stack from notebook iteration to data curation, evaluation, vector search, fine-tuning, and inference optimization. For an ML platform user, Hermes stops feeling like an assistant and starts feeling like a control plane that can carry procedures across the lifecycle. jupyter-live-kernel handles iterative exploration, evaluating-llms-harness and weights-and-biases formalize measurement, and the optional compute and optimization skills let Hermes talk coherently about both experimentation and deployment.

This is also the profile where restraint matters most. Because the optional MLOps catalog is so large, a production Hermes setup for ML work usually benefits from being opinionated about scope. A platform engineering profile that owns evaluation and deployment does not need every training framework installed. A research profile that owns papers and note systems does not need every vector database skill. Hermes can carry huge skill inventories, but production usefulness still comes from narrowing the active surface.

Where skills become liabilities

The strongest part of the Hermes skills system is also the place where production setups go wrong. Hermes can browse and install skills from its built-in catalog, the official optional catalog, Vercel's skills.sh, well-known skill endpoints, direct GitHub repositories, and marketplace-style community sources. The security model distinguishes between builtin, official, trusted, and community sources, runs security scans for hub-installed skills, and allows --force only for non-dangerous policy blocks. A dangerous scan verdict stays blocked. Hermes also surfaces upstream metadata such as repository URL, weekly installs, and audit signals during inspection. That is a solid trust model, but it is not a substitute for taste.

There is also a limit to what a skill should be asked to do. Hermes documentation is explicit that skills are the preferred choice when the job can be expressed as instructions plus shell commands plus existing tools, while plugins are the more honest abstraction for custom tools, hooks, and lifecycle behavior. The plugin guide even shows how a plugin can bundle its own skill. In production, that means skills are best treated as reusable procedures, not as a forced substitute for proper tool or plugin design.

Community and support look healthy, but they do not erase change velocity. Hermes documentation points users to Discord, GitHub Discussions, Issues, and the Skills Hub, and the public repository shows frequent releases and a large contribution footprint. The operational takeaway is simple enough: updates are part of the system, not an event outside it. A real production setup assumes profiles, skills, and workflow assumptions will evolve, then uses isolation and narrow skill packs so that change stays local when it inevitably arrives.

Hermes works best when skills are treated as procedural contracts around clearly separated profiles. The moment one profile becomes the engineering agent, the research assistant, the ops worker, the inbox bot, and the ML platform all at once, the system stops compounding and starts leaking responsibilities. The clean production pattern is less about having more skills and more about giving each profile a job description it can actually keep.

This article is part of the AI Systems cluster, which covers self-hosted assistants, retrieval architecture, local LLM infrastructure, and observability.

Backup and Restore Gitea server

Rost — Mon, 20 Apr 2026 09:47:17 +0000

Need to backup the 1) db, 2) filestorage, 3) some other gitea files. Here we go.

In the Testing Gitea post we installed the gitea server.

For the complete developer tools collection including Git workflows and Docker management, see Developer Tools: The Complete Guide to Modern Development Workflows.

If you're setting up Gitea for the first time, check out Choosing free on-prem git server - Gitea is the winner! for installation details, and Gitea SSL with Apache as reverse proxy for secure deployment.

When

Now just as a precaution of terrible things happenings, need to rehearse the backup and restore procedure.

Better be safe then sorry.

Where

Gitea server data consists of 3 components

code
filestore
db

In our test environment all togeather they take a bit more then 700MB:

As they recommend, need to stop all services and back up them all, kind of in the same transaction.

And restore, in the same transaction too.

How - Backup

cd ~/gitea-srv-local

# backup the db
sudo docker exec -t gitea-srv-local_db_1 bash -c 'pg_dump gitea -U gitea  --file=/var/lib/postgresql/backups/gitea-db-$(date +%Y-%m-%d).sql'

# take gitea down
sudo docker-compose down

# check the backups folder
sudo ls postgres-backups

# create backup dir
mkdir gitea-backups

# backup gitea folder
sudo tar -zcvf gitea-backups/gitea-gitea-$(date +%Y-%m-%d).tgz gitea/gitea

# backup repos folder
sudo tar -zcvf gitea-backups/gitea-git-$(date +%Y-%m-%d).tgz gitea/git

# bring it up
sudo docker-compose up -d

last bit - login to some other server and pull backup folder there, or do some other more elaborated files manipulation

scp -r uname@gitea-srv-ip-addr:/home/uname/gitea-srv-local/gitea-backups ~/gitea-backups
scp -r uname@gitea-srv-ip-addr:/home/uname/gitea-srv-local/postgres-backups ~/postgres-backups

How - Restore

Actually, there is a bit more then that, esp with permissions and hooks, but idea is the same.

But! check the original doco: https://docs.gitea.com/administration/backup-and-restore

# install it first
# then take it down
sudo docker-compose down

# restore files
tar -zxvf gitea-git-___.tgz gitea/git
tar -zxvf gitea-gitea-___.tgz gitea/gitea

# bring it up
sudo docker-compose up -d

# here some activity with psql or pg_restore
sudo docker exec -t gitea-srv-local_db_1 bash -c 'psql gitea -U gitea  --file=/var/lib/postgresql/backups/gitea-db-$(date +%Y-%m-%d).sql'

Then goto UI and check it

For quick reference on Git commands, see GIT Cheatsheet: Most useful GIT commands.

Useful links

DBeaver vs Beekeeper - SQL Database Management Tools

Rost — Mon, 20 Apr 2026 09:41:57 +0000

New Linux Ubuntu 24.04 desktop edition has offered me to install Beekeeper Studio as SQL Editor and DB Manager tool.
I was previously using DBeaver.
OK.
Let's Compare DBeaver with Beekeeper Studio.

This nice image is generated by the model AI model Flux 1 dev.

TL;DR

TL;DR means too long, didn't read for those who don't know...

Beekeeper studio is looking nice but still:

My choice of best DB management tool is still the same - DBeaver .
Main advantages of the DBeaver in my eyes are:

DBeaver can do backup and restore the SQL DBs
DBeaver has better license (Apache) comparing to Beekeper Studio (GGPL3)
In DBeaver you cen select output forma - grid or text. The text is better for copypasting. Don't call it advanced feature, Beekeeper, please...
Free Beekeeper Studio feels like intentionally cut version to push everyone to Pro one.

Detailed comparison of DBeaver and Beekeeper Studio

OK, here’s a detailed comparison of DBeaver and Beekeeper Studio, two popular database management tools:

Key Differences

Feature	Beekeeper Studio	DBeaver
User Interface	Modern, user-friendly, fast, and intuitive	Traditional, robust, may feel complex
Database Support	MySQL, PostgreSQL, SQLite, SQL Server, more	Relational & NoSQL (MongoDB, Cassandra, etc)
Query Editor	Intuitive, syntax highlighting, autocomplete	Comprehensive, execution plan visualization
Migration Tools	Streamlined, easy-to-use migration wizards	Supports migrations, less streamlined
Data Visualization	Basic charting, table previews	Advanced charts, dashboards, reports
Collaboration	Built-in collaboration for simultaneous work	No native collaboration; supports Git
Learning Curve	Minimal, easy to start	Moderate, more features to learn
Performance	Lightweight, fast	Can be slower due to feature density
License	Open source (GPLv3), free & paid tiers	Open source, free & paid versions

Strengths

Beekeeper Studio

Ease of Use: Designed for simplicity and speed, with a modern UI that feels like a code editor (similar to VSCode).
Quick Start: Minimal learning curve, suitable for users who want to get work done without complex setup.
Collaboration: Built-in tools for team-based database work.
Privacy: No telemetry or tracking in the community edition.

DBeaver

Feature Density: Extensive features for advanced users, including support for a wide range of database types (relational and NoSQL).
Data Visualization: Advanced charting and reporting tools.
Version Control: Integration with Git for team collaboration via code repositories.
Universal Support: Broad compatibility with obscure or legacy databases via JDBC.

Use Cases

Choose Beekeeper Studio if you prioritize a fast, modern, and easy-to-use tool for SQL work, especially if you work with mainstream databases and value collaboration and privacy. For SQL command references, see SQL Cheatsheet.
Choose DBeaver if you need support for a wide variety of databases (including NoSQL), advanced data visualization, or integration with version control systems.

DBeaver offers superior support for NoSQL databases—including both Redis and MongoDB—compared to Beekeeper Studio.

DBeaver: Supports a wide range of NoSQL databases such as MongoDB, Cassandra, Redis (via JDBC or plugins), and more. Its advanced database management features, including schema browsing, query building, and data visualization, make it a strong choice for users who need to work with various NoSQL solutions. DBeaver’s extensions and plugins further enhance its compatibility with these databases.
Beekeeper Studio: Primarily focused on relational databases (e.g., MySQL, PostgreSQL, SQLite, SQL Server). While it is user-friendly and modern, current versions do not provide native or robust support for NoSQL databases like MongoDB or Redis.

Summary

Beekeeper Studio offers a more user-friendly and streamlined experience, while DBeaver provides broader database support and advanced features at the cost of a steeper learning curve. The choice depends on your workflow, database needs, and preference for simplicity versus feature richness.
If your primary need is working with NoSQL databases such as Redis and MongoDB, DBeaver is the better choice.
Beekeeper Studio is more suitable for relational database management.

For PostgreSQL-specific commands, check out the PostgreSQL Cheatsheet.

And I like DBeaver more.

Useful links

Kubuntu vs KDE Neon: A Technical Deep Dive

Rost — Sun, 19 Apr 2026 04:48:01 +0000

For KDE Plasma fans, two Linux distributions frequently come up in discussion:
Kubuntu and KDE Neon.
They may appear similar - both ship with KDE Plasma as the default desktop, both are based on Ubuntu, and both are friendly to newcomers.

But under the hood, they diverge in philosophy, update cadence, and package management. Let's break them down in technical detail.

For more developer tools comparisons, see Developer Tools: The Complete Guide to Modern Development Workflows.

Base System and Repositories

Kubuntu
- Built as an official Ubuntu flavor.
- Uses Ubuntu repositories (main, universe, multiverse, restricted) plus the Kubuntu PPAs maintained by the Kubuntu team.
- Plasma and KDE applications are snapshotted per Ubuntu release cycle, meaning you only get newer KDE versions when upgrading to the next Kubuntu release (unless you manually add backports).
KDE Neon
- Built on top of Ubuntu LTS releases only (e.g., 22.04 LTS).
- Core system packages (kernel, drivers, base libraries) come from Ubuntu LTS repositories.
- KDE packages (Plasma desktop, Frameworks, and Applications) come directly from the KDE Neon repositories, which are maintained by KDE developers.
- Uses a hybrid model: stable Ubuntu LTS base + rolling-release KDE stack.

Update and Release Cycle

Kubuntu
- Release cycle mirrors Ubuntu: every six months (April and October).
- LTS releases every two years with 5 years of support.
- KDE updates are delivered at the point release stage. Between upgrades, KDE Plasma versions stay frozen (unless you use the Kubuntu Backports PPA).
- Example: Kubuntu 22.04 shipped with Plasma 5.24 LTS and won’t get Plasma 5.27 unless the user opts into backports.
KDE Neon
- The Ubuntu base remains fixed (e.g., still on 22.04).
- KDE software is updated within days of upstream release.
- Users receive Plasma point releases, Frameworks, and Application updates through standard APT upgrades.
- Example: Plasma 5.27 becomes available to Neon users almost immediately after KDE publishes it.

Package Management

Both use APT/dpkg as their package management system, but their package sources differ.

Kubuntu:
- apt pulls from Ubuntu archives and Kubuntu PPAs.
- Snap integration comes by default, as per Ubuntu policy.
- Flatpak available but not preconfigured.
KDE Neon:
- apt pulls core from Ubuntu LTS + KDE Neon’s own repos.
- KDE Neon avoids Snap by default, focusing on DEB packages.
- Flatpak is often recommended for newer non-KDE apps.
- Because KDE software is packaged directly by KDE devs, you often see newer versions compared to Ubuntu/Kubuntu.

Kernel and Driver Updates

Kubuntu
- Follows Ubuntu kernel and driver updates.
- Hardware Enablement (HWE) kernels available on LTS.
- Kernel updates tied to Ubuntu release cycle.
KDE Neon
- Since the base is Ubuntu LTS, kernel updates come from Ubuntu LTS + HWE stack.
- Neon doesn’t modify kernel or drivers — focus is purely on KDE software.

Stability and Regression Risks

Kubuntu
- Stable because Plasma and KDE apps are frozen until the next release.
- Fewer regressions because software versions are heavily tested.
- Risks come mainly when upgrading between Ubuntu versions (e.g., 22.04 → 22.10).
KDE Neon
- More prone to regressions since you’re on bleeding-edge KDE builds.
- Users sometimes face issues after major Plasma updates (e.g., panel crashes, KWin bugs).
- However, KDE Neon acts as a testing ground, so bugs are quickly reported and patched by KDE devs.

Target Use Cases

Kubuntu:
- Enterprises, developers, and users who want a “set it and forget it” system.
- Ideal for those who rely on long-term stability (e.g., LTS versions).
- Works well in production and business setups.
KDE Neon:
- Enthusiasts, testers, and developers who want the latest KDE software.
- Great for people contributing to KDE or reporting bugs upstream.
- Not always ideal for mission-critical environments due to its rolling KDE nature.

Resource Usage and Performance

Plasma itself is efficient, and both distros perform similarly on the same hardware.
Kubuntu: Slightly more conservative with background services, since it adheres to Ubuntu defaults.
Neon: Sometimes lighter initially, but Plasma updates may introduce new services or defaults faster than Kubuntu.

Community and Support

Kubuntu:
- Official Ubuntu flavor → benefits from Ubuntu forums, AskUbuntu, Launchpad bug tracking.
- Kubuntu team maintains additional documentation and a strong IRC/Telegram community.
KDE Neon:
- Supported directly by KDE devs and community.
- Bugs in KDE software can be reported directly upstream to KDE, rather than Ubuntu.
- Smaller support base outside of KDE-specific issues, but relies on Ubuntu docs for general system problems.

TL;DR — Key Differences in Table Form

Feature	Kubuntu	KDE Neon
Base	Ubuntu (regular releases + LTS)	Ubuntu LTS only
Update cycle	Fixed, tied to Ubuntu	Rolling KDE on fixed Ubuntu LTS
KDE updates	Frozen per release (backports optional)	Immediate, within days of upstream
Package sources	Ubuntu repos + Kubuntu PPAs	Ubuntu LTS repos + Neon KDE repos
Snap support	Included by default	Not included by default
Stability	Very stable	Stable base, but KDE is bleeding-edge
Target users	General desktop & enterprise	KDE enthusiasts, testers, devs

Conclusion

While Kubuntu is a rock-solid Ubuntu flavor offering a predictable, stable KDE Plasma experience, KDE Neon acts as a rolling showcase of the KDE ecosystem, with Plasma updates delivered almost instantly.

Choose Kubuntu if you want stability, long-term support, and predictability.
Choose KDE Neon if you want the latest KDE tech, rapid updates, and direct integration with KDE development.

Both are excellent — the decision comes down to whether you prioritize stability or innovation.

Useful links

Little Ubuntu Linux Howtos:

Gitflow Explained: Steps, Alternatives, Pros, and Cons

Rost — Sun, 19 Apr 2026 04:35:33 +0000

Gitflow is widely used in projects requiring versioned releases, parallel development, and hotfix management.

This guide is part of Developer Tools: The Complete Guide to Modern Development Workflows.

By separating development, testing, and production environments into distinct branches, Gitflow ensures predictable deployments and clear traceability of changes. Its importance lies in its ability to scale for large teams and maintain stability in complex projects.

Gitflow is a branching model introduced by Vincent Driessen in 2010, designed to manage complex software development workflows with structured release cycles.

2. Definition and Core Concept of Gitflow

Gitflow is a branching strategy that organizes workflows around five primary branches:

main/master: Stores production-ready code (stable releases).
develop: Acts as the integration branch for ongoing development.
feature/xxx: Short-lived branches for developing new features.
release/xxx: Created from develop to prepare for production releases.
hotfix/xxx: Branches from main to address critical production bugs.

The core concept is to isolate work (features, releases, hotfixes) into dedicated branches, ensuring that production code remains stable while allowing parallel development and testing.

3. Step-by-Step Sequence of Actions in Gitflow

The Gitflow workflow follows a structured process:

Initialize Gitflow:
- Use git flow init or standard Git commands to set up main and develop branches.
- Before starting, ensure you've Configure Git User Name and Email Address.
- For a comprehensive list of Git commands, see GIT Cheatsheet: Most useful GIT commands.

Start a Feature:

Create a feature branch from develop:

 git checkout develop  
 git checkout -b feature/new-feature

(Alternative): git flow feature start new-feature
1. Develop the Feature:
Commit changes to the feature branch.
1. Finish the Feature:

Merge into develop and delete the branch:

 git checkout develop  
 git merge feature/new-feature  
 git branch -d feature/new-feature

(Alternative): git flow feature finish new-feature
1. Prepare a Release:

Create a release branch from develop:

 git checkout develop  
 git checkout -b release/1.2.0

(Alternative): git flow release start 1.2.0
1. Finalize the Release:

Merge into main and develop, tag the release:

 git checkout main  
 git merge release/1.2.0  
 git tag -a 1.2.0 -m "Release version 1.2.0"  
 git checkout develop  
 git merge release/1.2.0  
 git branch -d release/1.2.0

(Alternative): git flow release finish 1.2.0
1. Handle Hotfixes:

Create a hotfix branch from main:

 git checkout main  
 git checkout -b hotfix/critical-bug

(Alternative): git flow hotfix start critical-bug

Merge into main and develop, tag the hotfix:

 git checkout main  
 git merge hotfix/critical-bug  
 git tag -a 1.2.1 -m "Hotfix version 1.2.1"  
 git checkout develop  
 git merge hotfix/critical-bug  
 git branch -d hotfix/critical-bug

(Alternative): git flow hotfix finish critical-bug

4. Typical Workflow Stages and Branching Strategy

Gitflowâ€™s branching strategy ensures separation of concerns:

Feature branches allow parallel development without affecting develop.
Release branches provide a testing environment for finalizing releases.
Hotfix branches enable urgent bug fixes without disrupting ongoing development.

Key stages include:

Feature Development â†’ 2. Integration into develop â†’ 3. Release Preparation â†’ 4. Stabilization and Deployment â†’ 5. Hotfix Handling.

5. Common Use Cases and Scenarios for Gitflow

Gitflow is ideal for:

Large teams requiring structured collaboration.
Projects with scheduled releases (e.g., enterprise software, regulated industries).
Complex systems requiring versioned deployments (e.g., multi-tenant applications).
Teams needing isolation between development, testing, and production environments.

6. Overview of Gitflow Alternatives

GitHub Flow

Workflow: Single main branch with short-lived feature branches.
Steps:
1. Create a feature branch from main.
2. Merge via pull request after testing.
3. Deploy directly to production.
Advantages: Simplicity, CI/CD compatibility, rapid deployment.
Disadvantages: No structured release management; unsuitable for versioned projects.

GitLab Flow

Workflow: Combines GitHub Flow with environment-specific branches (e.g., staging, production).
Advantages: Balances simplicity and structure for hybrid workflows.

Trunk-Based Development

Workflow: All changes are merged directly into main using feature flags.
Advantages: Reduces branching overhead, supports CI/CD.
Disadvantages: Requires mature testing pipelines and disciplined teams.

Branch Per Feature

Workflow: Each feature is developed in its own branch, merged into main after testing.
Advantages: Isolates features, reduces conflicts.
Adoption: Used by companies like Spotify and Netflix.

7. Weaknesses and Limitations of Gitflow

Complexity:
- Managing multiple branches increases merge conflicts and overhead.
- Requires strict branch hygiene and discipline.
Not Ideal for CI/CD:
- The branching model is rigid for continuous delivery environments.
Risk of Merge Conflicts:
- Long-lived branches (e.g., develop, release) can diverge, leading to integration issues.
Learning Curve:
- New developers may struggle with branching rules and merge strategies.
Slower Releases:
- Multi-step processes (e.g., release â†’ develop â†’ main) can delay deployments.

8. Advantages and Benefits of Using Gitflow

Structured Release Management:
- Clear separation of features, releases, and hotfixes.
Stability:
- Ensures main remains production-ready at all times.
Version Control:
- Semantic versioning and tagging improve traceability and reproducibility.
Collaboration:
- Enables parallel development and isolated testing.
Hotfix Efficiency:
- Critical fixes can be applied to main without disrupting ongoing development.

9. Comparison: Gitflow vs. Alternative Workflows

Aspect	Gitflow	GitHub Flow	Trunk-Based Development
Branching Model	Multi-branch (feature, develop, release, hotfix, main)	Minimal (main + feature branches)	Single `main` branch with feature flags
Release Process	Structured with release branches	Direct deployment from main	Continuous deployment from `main`
Complexity	High (suitable for large projects)	Low (ideal for agile, small teams)	Low (requires mature CI/CD)
Merge Frequency	Frequent (across multiple branches)	Minimal (fewer merges)	Frequent (direct to `main`)
Testing Requirements	Rigorous (for release/hotfix branches)	Automated tests critical for main	Automated tests for feature flags

10. Best Practices for Implementing Gitflow

Automate Workflows: Use CI/CD tools (e.g., Jenkins, GitHub Actions) to reduce manual effort.
Enforce Branch Naming Conventions: Standardize branch names (e.g., feature/{name}) for clarity.
Regular Sync Meetings: Ensure alignment between teams to address bottlenecks.
Automated Dependency Management: Use tools like Dependabot to manage outdated dependencies.
Merge Strategy: Use --no-ff merges to preserve feature history.

11. Case Studies or Real-World Examples

Large Enterprises: Companies like Microsoft and IBM use Gitflow for managing complex releases in legacy systems.
Open-Source Projects: Gitflow is less common in open-source due to its complexity but is used in projects requiring long-term maintenance (e.g., Kubernetes).
Hybrid Workflows: Teams like GitLab use GitLab Flow to combine Gitflowâ€™s structure with GitHub Flowâ€™s simplicity.

12. Conclusion and Final Thoughts on Gitflowâ€™s Relevance

Gitflow remains a robust solution for structured release management in large, complex projects. Its strengths in version control, stability, and collaboration make it ideal for teams with scheduled release cycles and regulatory compliance requirements. However, its complexity and overhead make it less suitable for small teams, agile environments, or CI/CD pipelines.

Alternatives like GitHub Flow (for simplicity) and Trunk-Based Development (for CI/CD) offer trade-offs in flexibility and scalability. The choice of workflow depends on team size, project complexity, and release frequency. As DevOps practices evolve, Gitflowâ€™s role may shift toward hybrid models that combine its structure with modern automation tools.

Final Recommendation:

Use Gitflow for large-scale, versioned projects.
Adopt GitHub Flow or Trunk-Based Development for smaller teams or CI/CD environments.
Customize workflows based on team needs and project scope.

Forem: Rost

OpenClaw Rise and Fall — Timeline and Real Reasons Behind the Collapse

The illusion of product-driven growth

Phase 1. Quiet emergence (November 2025)

Phase 2. The viral ignition (January–February 2026)

1. Naming drama and forced rebrands

2. The agent hype wave

3. The cheap compute loophole

Phase 3. Peak usage and inflated expectations

Why do AI tools suddenly become popular and then fade

The creator leaves for OpenAI (February 2026)

Phase 4. The correction begins

1. Reality of agent limitations

2. The economic layer breaks

What caused the sudden drop in interest in AI agent tools

April 4, 2026 — The hard cutoff

OpenAI moves in the opposite direction

Phase 5. Where OpenClaw users actually went

Direct usage of chat assistants

Are AI agents replacing traditional chat assistants

Cheaper model ecosystems

Which models are popular for low-cost AI experimentation

Alternative agent frameworks

The overlooked factor — why cost is the real product

Why is cost important in AI adoption

OpenClaw was never the core story

The pattern repeats across AI

OpenClaw vs Hermes Agent — what the trend data shows

Final takeaway — follow the economics, not the interface

Llama-Server Router Mode - Dynamic Model Switching Without Restarts

Prerequisites

What router mode actually does

The key idea

Configuration: defining your models

Example models.ini

Key config parameters

Starting the server with config

A note on stability

API usage: switching models on request

List registered models

Completion request — first model

Switch to a different model — same endpoint, same port

Python example

What happens internally

Systemd service: production-ready setup

Create a dedicated user and directories

/etc/systemd/system/llama-server.service

Enable and start

Verify and inspect logs

Limitations you need to understand

Only one model in memory at a time

No smart caching

Latency is unpredictable for mixed workloads

Config is not stable

Llama.cpp vs Ollama: honest comparison

Opinionated take

Llama.cpp vs llama-swap

Key difference

When to use llama-swap

When native router mode is enough

Final thoughts

Claude Skills and SKILL.md for Developers: VS Code, JetBrains, Cursor

When to Use Claude Skills: CLAUDE.md vs Skills vs Hooks

Claude Skills IDE Support: VS Code, JetBrains, Cursor, and Codex

SKILL.md File Structure, Folder Layout, and Storage Locations

Claude Skills Best Practices: Descriptions, Scripts, and Scope

Testing Claude Skills: Triggers, Correctness, and Baseline Comparisons

Claude Skills Troubleshooting: Common Failures and Fixes

Pause Scripts with 'Press Any Key' in Bash, CMD, PowerShell, and macOS

When to pause (and when not to)

Windows CMD

PowerShell

Wait for Enter only

Wait for any key (Windows console)

Bash (Linux and macOS)

macOS notes

POSIX sh (portable “press Enter”)

Cross-platform branching

Related reading

Useful links

POSIX `sh` (portable “press Enter”)