# Three rules for picking the first plugin you actually keep
The first wave of plugin enthusiasm is the most expensive moment in any new OpenClaw workspace. Everything looks useful. Every skill feels like it will solve some future problem. Within two weeks most of those plugins are disabled, the workspace is cleaner, and the operator is slightly more cynical.
This piece is about avoiding that two-week loop. Three filters, applied before install, sort the durable plugins from the rest.
Rule 1: the plugin must answer a question you already have
The most common early-plugin mistake is installing something because it seems like it might answer a question. The plugin's README describes a use case, you can imagine a scenario where the use case matters, and the install button is right there.
The hard rule: if you cannot name a current question that the plugin will answer, do not install it yet. "Current" means something you have already thought about in the last week — not a hypothetical you read about.
A diagnostic phrasing that works:
> "I am about to install plugin X. The question it will answer is > ____. I last wanted to answer that question on ____."
If either blank is empty, the plugin is for a future version of the operator who has more questions. That future version can install it later. Today's job is to keep the workspace understandable.
Rule 2: the plugin must be inspectable on a bad day
A plugin that works perfectly when nothing is going wrong is not the plugin you need. The plugin you need is one whose failure modes are visible and named.
Before installing, ask:
- What does this plugin do when its remote endpoint is unavailable?
- Does it cache, retry, or surface the error?
- If it modifies a file, can I see the diff afterward?
- If it sends a message, can I see what was sent?
The reason this matters: every plugin that quietly fails in the background is a plugin that, six months from now, will be the cause of a 45-minute investigation whose root cause is "the plugin stopped working silently three weeks ago and we didn't notice." That investigation is more expensive than the time saved by the plugin's nominal function.
If the answer to any of those questions is "I don't know," treat that as a no. A plugin whose failure mode is unknown is a plugin that will eventually be uninstalled under pressure. Better to learn that now.
Rule 3: the plugin must be worth disabling later
Every durable plugin is a plugin you have, at some point, turned off on purpose. If you cannot articulate the conditions under which you would disable it, you cannot decide whether the plugin is still pulling its weight six months from now.
The disabling criteria are not the same as the disabling decision. The decision is "should I remove this." The criteria are the specific signals that would make the decision obvious — a count of failed calls per week, a percentage of outputs that need manual cleanup, a number of incidents where the plugin was the proximate cause.
A plugin with no disabling criteria is a plugin that lives in the workspace forever, because removing it would feel like an admission that the install was wrong. Operators who keep those plugins forever also keep the cognitive load of maintaining them forever.
Putting the three together
The three rules are not a checklist for every install. They are a filter that, applied loosely, will reject the majority of first-wave plugins and accept the minority that earn their place.
A plugin that passes all three:
- Has a question it answers that you have today.
- Has a failure mode you can see and name.
- Has a disabling threshold that would make the uninstall decision
obvious.
That kind of plugin is durable. The install costs you a few minutes; the ongoing cost is small enough to ignore; and if the plugin eventually fails you, you can see when it failed and decide what to do about it.
What this rule is not
It is not a rule against trying new plugins. Workspace isolation means an experimental install is cheap. The rule is against letting an experimental install become a permanent one without re-checking it against the three filters later.
A workable cadence: every three months, walk through the enabled plugins list and apply the three filters again. A plugin that passed once and now fails one of them is a plugin that has outlived its usefulness. Uninstalling it is not a failure — it is the rule working.