Open source
Why We Open-Sourced Our Versioned Agent Skills
Public, versioned skill bundles make agent instructions inspectable, testable, installable, and less likely to drift from the services they invoke. The source repository becomes the review surface; the registry remains the distribution surface; tests prove the release matches the intended instructions.
Answer first
Public, versioned skill bundles make agent instructions inspectable, testable, installable, and less likely to drift from the services they invoke. The source repository becomes the review surface; the registry remains the distribution surface; tests prove the release matches the intended instructions.
Agent instructions are executable infrastructure
A skill may look like documentation, but an agent can treat it as an operating procedure. It can influence which endpoint is called, which credential is used, what information is stored, when the agent stops, and how a failure is interpreted. That makes the instruction bundle part of the product's security and reliability boundary.
We open-sourced the Sentien Labs OpenClaw bundles because operators should not have to trust an opaque marketplace archive. They should be able to inspect the exact files, compare versions, run checks, and report a specific defect.
Source and distribution have different jobs
GitHub is the review, history, testing, and contribution surface. ClawHub is the versioned distribution surface. The two should converge on the same release bytes, but they serve different people and workflows.
- Source makes changes inspectable before installation.
- Versioned registry releases give operators stable install targets.
- Changelogs explain why behavior or permissions changed.
- Parity checks detect a marketplace bundle that no longer matches its reviewed source.
The cleanup found real risks
Reviewing the live catalog surfaced more than stale marketing. One service-adjacent path treated a nonempty payment-proof header as if payment had been verified. A memory skill had defaults that could load personal profiles in shared contexts and let automation rewrite long-term memory without enough review.
Those findings changed both the code and the instructions. The payment bypass was removed. Memory behavior became private-session-only by default, explicitly opt-in, review-before-write, and bounded by retention and deletion controls.
What a release check should prove
- No retired endpoint, tool name, domain, price, quota, or unsupported chain remains.
- Clean installation produces the expected files and nothing extra.
- Setup scripts default to dry-run, preserve existing files, and remain idempotent.
- Secrets and shared-channel behavior are explicitly bounded.
- The installed registry release matches the reviewed source.
- The live service contract still agrees with the instructions.
A marketplace security scan adds evidence, but it does not replace these product-specific checks. Static scanning cannot prove that a remote API response still has the fields a skill teaches the agent to interpret.
What stays private
Open-sourcing a skill does not require publishing service credentials, private product code, customer data, internal deployment configuration, or security material that would increase operational risk. The public bundle should contain the instructions and assets needed to understand and run the integration—nothing more.
The practical outcome
Versioning does not make an agent safe by itself. It makes safety work reviewable. When an operator can point to an exact release, reproduce the install, see its permissions, and compare it with the live service contract, defects become easier to find and less likely to hide inside a friendly marketplace description.
That is the reason to open the source: not because every instruction belongs in public, but because operational instructions distributed to other people's agents should earn trust through evidence.