Before a community OpenClaw skill enters a shared workspace

Published June 2, 2026 · OpenClawBlog Team

A colleague finds a community OpenClaw skill that appears to solve a small problem. Copying it into a workspace may take a minute. Deciding whether the whole team should inherit it deserves more care.

The question is not whether the skill produced one convincing answer. It is what the skill can cause an agent to read, call, or change when the agent has access to shared files and tools. OpenClaw describes skills as Markdown instruction files, but a skill folder can also contain scripts, templates, references, and other supporting files. Workspace skills also take precedence over several other skill locations. That makes a shared skill closer to a shared dependency or configuration change than to a private prompt. See the OpenClaw skills reference and ClawHub registry guide.

My suggested rule is simple: admit a community skill in stages. Keep it with one reviewer first, pilot it with synthetic data, promote one fixed version to the agreed shared location, and review it again when its source or purpose changes. If the team cannot name the task, owner, authority, and exit path, the skill is not ready for the shared workspace.

Define what shared means

OpenClaw has more than one way to make a skill available. The current documentation distinguishes per-agent workspace skills, project-agent skills, personal and managed roots, workshop skills, and extra directories. A managed shared root can be visible to all agents using the same state, while an agent allowlist can narrow which skills a particular agent sees. Location and visibility are separate decisions.

This table is an editorial decision aid based on the documented loading model, not an OpenClaw policy. Start with the narrowest visibility that can answer the team question. A name collision also matters: when the same skill name appears in multiple places, the higher-precedence copy wins. A reviewer who checks one folder but runs another copy has not reviewed the artifact that matters.

A shared workspace is not automatically a multi-user security boundary. OpenClaw says the workspace is the agent's default working directory, not a hard sandbox. Absolute paths can still reach elsewhere on the host unless sandboxing is enabled. The project's security policy also describes a shared Gateway as a trusted-operator model rather than a multi-tenant bus. Session identifiers route conversations; they do not create per-user authorization. If team members are mutually untrusted, use a separate operating-system user, host, or Gateway boundary instead of trying to solve the problem with a shared skill folder. See the agent workspace documentation, the multi-agent routing documentation, and the project's security policy.

Write the admission packet first

Before installation, create a short record that another teammate can read without opening a chat transcript. This is a proposed team process. The fields below turn a vague approval into something that can be repeated after an update.

ClawHub listings expose useful provenance: an owner or publisher, versions, metadata, source attribution, changelog information, usage signals, and scan or moderation state. The listing is the right place to start, but the listing is a description of the release. It is not a substitute for reading the release that will enter your workspace.

Read the bundle, not only the summary

The official skill format defines a skill as a folder containing a SKILL.md file or accepted legacy equivalent, with optional supporting files. Frontmatter can declare the name, description, environment variables, required binaries, configuration paths, operating-system limits, and dependency installation details. Those declarations give the team a checklist.

Read the complete folder at the exact version recorded in the packet. Compare the stated job with the trigger wording. Look at every referenced script and URL. Check whether an installer downloads more code, whether a helper writes to a path outside the expected workspace, and whether a supposedly local workflow asks for a credential or network connection. A short SKILL.md can still direct an agent to use powerful tools that the agent already has.

Stop and reclassify the package if it contains an OpenClaw plugin manifest or another runtime bundle. A native plugin is a different trust decision: OpenClaw's security policy says plugins and extensions load in process with the Gateway and receive the trust level of local code on that host. A team should not approve such a package through a lightweight skill checklist. It needs the organization's normal code and dependency review.

Popularity does not close the gap. Downloads, stars, a polished description, and a familiar publisher name are useful context. None tells you whether the current files match the task. Treat the source, version, and contents as the object under review.

Interpret ClawHub checks without outsourcing the decision

ClawHub's security audit documentation separates audit status from risk level. Pass means that no visible issue above low risk was found. Review means the findings need to be read. Warn calls for extra caution. Malicious means do not install. Pending means the audit is unfinished, and Error means it could not be completed. Risk level describes the apparent blast radius, while status describes how the result should affect the installation decision.

The same documentation says a Pass is not a guarantee that a release is risk-free. It also lists the material checks: declared permissions and environment variables, install instructions, included files, compatibility information, and whether the release's behavior matches its description. That gives a team a useful interpretation:

• Reject a Malicious result.
• Defer a Pending or Error result until the missing evidence is available.
• Require a named reviewer for Review or Warn.
• Do not let a Pass replace the authority and side-effect review.

These are editorial gates, not claims that ClawHub assigns your organization's approval. They keep a green signal in proportion to what it actually says.

Match authority to the job

Make an access budget before the pilot. The budget should describe what the skill needs, not everything the agent could theoretically do.

This is a proposed triage, not an OpenClaw classification system. The official skills reference is clear about one limit: an allowlist controls which skills an agent can see, but it is not a host shell authorization boundary. If the agent can use exec, constrain that separately with sandboxing, operating-system isolation, tool policy, and credentials scoped to the resource. The workspace itself is also not a sandbox.

Run a pilot that can fail safely

The following are proposed team tests, not hands-on results from this article. Before the first run, prepare a disposable agent or workspace, a fixed artifact version, synthetic input, a reviewer who did not write the approval note, and a copy of the previous state. Do not place customer records, production tokens, private browser sessions, or irreplaceable files in the fixture.

1. Record the baseline. Note the OpenClaw version, active agent, workspace path, installed skills, and the exact source reference.
2. Use a small fixture with a known expected result and one deliberate gap. The gap shows whether the skill asks for clarification or fills in an unsupported answer.
3. Run the normal case with a fixed prompt. Save the output and record which files, processes, network calls, and messages were involved.
4. Run an edge case. Use missing input, an out-of-scope request, or source content that tries to redirect the workflow. The expected result should be a clear stop or error, not a wider task.
5. Repeat the check after returning to a clean workspace. If the second run depends on leftovers from the first, record that dependency or stop the admission.
6. Compare the result with the authority map. A useful answer with an unexplained file write or network request is a failed boundary check.

A plausible paragraph is only a functional result. It does not prove that the skill stayed inside the intended boundary. Keep those two conclusions separate in the packet.

Choose an outcome the team can explain

Use four outcomes rather than forcing every candidate into approve or reject:

• Shared: The task, source, authority, owner, visibility, pilot result, and rollback path are recorded.
• Restricted pilot: The skill stays with one named agent or reviewer while the missing evidence is collected.
• Deferred: The package may be useful, but its publisher, files, audit state, requirements, or update path remain unclear.
• Rejected: The artifact is mismatched, hides material behavior, asks for disproportionate access, or cannot be tested safely.

ClawHub's acceptable usage guidance gives a sensible minimum for team workflows: transparent setup, consent-based accounts, explicit permissions, and review, dry-run, preview, or confirmation paths for risky actions. Your approval note should make those details visible to the people who will inherit the skill.

Updates are new admissions

ClawHub describes published versions as immutable records with their own metadata and source information. A later version is therefore a new object to review, even if the name and description did not change. Recheck the files, triggers, requirements, audit state, and authority map. A moving branch or automatic update makes that comparison harder, so record the resolved version or commit for the team pilot.

Keep the reviewed artifact and the previous team decision available to the maintainer. Removal is not a complete rollback if the skill already changed files, added configuration, or sent data to an external service. The packet should say what the team will restore and who is allowed to do it.

Failure paths that should stop promotion

• The listing says local document formatting, but the bundle asks for an API key, broad network access, or a publishing script.
• The audit is Pending or Error and nobody can explain why the missing result is acceptable.
• The team finds two copies with the same skill name and cannot prove which one the agent loads.
• The only successful test uses real customer data or a production account.
• No one owns updates, the source cannot be pinned, or the removal path depends on an administrator who is not part of the project.
• The team wants per-user privacy from a shared Gateway. A skill folder cannot provide that boundary.

The ClawHub moderation guidance also separates marketplace reports from source-code vulnerabilities. Report unsafe listings, misleading metadata, undeclared permissions, or suspicious install instructions through the marketplace process. Report a defect in a third-party skill's own code to its publisher or linked source repository. Keeping those paths separate makes the incident record more useful.

A worked example without pretending it is a real package

Imagine a hypothetical community skill called weekly-report. Its listing says it reads three local CSV files and produces a Markdown summary. The team packet records the publisher and a fixed version. The first inspection finds SKILL.md, a Python helper named publish.py, a required REPORT_API_KEY, and an instruction to post the finished report to a webhook. The ClawHub result is Review with Medium risk.

The report generation may be legitimate. The shared-workspace decision is still no, at least for now. The artifact asks for more authority than the stated local task needs. The team could request or build a version without the publishing path, or test the full workflow in a restricted agent with a disposable account and explicit confirmation before sending. If the publisher cannot explain the mismatch, reject the package. The point is not that external publishing is always wrong. It is that the extra authority must be visible and owned before everyone inherits it.

The standard to keep

A community OpenClaw skill is ready for a shared workspace when the team can state what it reads, what it may cause, where it loads, who maintains it, and how to remove it. If one of those answers depends on popularity, a green badge, or an assumption about the sandbox, keep the skill in the restricted stage. A smaller shared surface is easier to review and easier to recover.

Sources

Sources accessed 2026-09-13. The official documentation pages and repository policy did not state publication dates, so the publication field is left empty in the source record.

• OpenClaw: Skills
• OpenClaw: How ClawHub Works
• OpenClaw: Skill format
• OpenClaw: Security Audits
• OpenClaw: Acceptable Usage
• OpenClaw: Moderation and Account Safety
• OpenClaw: Agent workspace
• OpenClaw: Multi-agent routing
• OpenClaw: Security policy