Release Openclaw Plugin Testing logo

Release Openclaw Plugin Testing

OrganizationPopular
openclaw
release-openclaw-plugin-testing

Plan and run pre-release OpenClaw plugin validation across bundled plugins, package artifacts, lifecycle commands, doctor/fix, config round-trip, gateway startup, SDK compatibility, Docker E2E, Package Acceptance, and Testbox proof.

Overview

Publisheropenclaw
Repositoryopenclaw
Skill namerelease-openclaw-plugin-testing
Stars
391K
Forks
82.2K
Bundled files
1
Links
  • Markdown instructions

    A SKILL.md file the model loads on demand, so it only costs tokens when a request actually matches.

  • Works with any LLM

    AI skills are plain Markdown, not provider-specific code, so this works with GPT, Claude, Gemini, Grok, or a local model.

  • 1 bundled files

    Scripts, templates, and references the model can read while it works. Files are read-only and never executed.

  • Open source

    Published by openclaw on GitHub. Read the source before you install it.

Installation

Install the Release Openclaw Plugin Testing AI skill in TypingMind to use it with any LLM, or drop it into another agent that reads SKILL.md.

1

Install in TypingMind

TypingMind installs a skill straight from its GitHub folder — it reads SKILL.md, bundles the resource files, and stores the result locally.

  1. Open the app and go to Plugins → Skills.
  2. Choose "Install from GitHub".
  3. Paste the skill folder URL below and confirm.
    https://github.com/openclaw/openclaw/tree/main/.agents/skills/release-openclaw-plugin-testing
  4. Enable the skill in any chat where you want it available.
Plugins → Skills → Add skill → From GitHub URL, then paste the folder URL and press Continue.
2

Install in another agent

Any agent that reads the Agent Skills format can use this skill — copy the folder into that agent's skills directory.

Claude Code — .claude/skills
git clone --depth 1 https://github.com/openclaw/openclaw.git /tmp/openclaw
mkdir -p .claude/skills
cp -r /tmp/openclaw/.agents/skills/release-openclaw-plugin-testing .claude/skills/release-openclaw-plugin-testing
Restart Claude Code after copying so it picks up the new skill.

Use it in TypingMind

Enable Release Openclaw Plugin Testing in any TypingMind chat and the model takes it from there. Its name and description sit in the system prompt, and the moment a request matches, the model loads the full instructions itself — you never invoke it by hand, and it costs no tokens until it is actually used.

The model loads Release Openclaw Plugin Testing on its own as soon as a request matches it.

Works with any AI model

AI skills are plain Markdown instructions rather than provider-specific code, so Release Openclaw Plugin Testing is not tied to the model it was written for. Install it once in TypingMind and use it with GPT-5, Claude, Gemini, Grok, DeepSeek, Mistral, Llama, or a local model you run yourself — all on your own API keys.

  • Loaded only when it is needed

    The system prompt carries just the name and description. The instructions are fetched on the first matching request, so an idle skill costs nothing.

  • Switch models mid-chat

    Because the skill is instructions rather than code, changing model does not break it — the next model reads the same SKILL.md.

Skill instructions

This is the SKILL.md content the model loads. Read it before installing — a skill is instructions your model will follow.

OpenClaw Pre-Release Plugin Testing

Use this skill when the user asks for plugin release confidence, plugin lifecycle sweeps, package-artifact plugin proof, or "what else should we test before release?" It complements openclaw-testing; use that skill too when choosing the cheapest safe runner or debugging a failing lane.

Goal

Prove the plugin system as a product surface, not just as source tests:

  • bundled plugin lifecycle: install, inspect, enable, disable, uninstall
  • package artifact behavior from a clean HOME
  • doctor/fix/config validation and idempotence
  • config discovery and config round-trip
  • status/log visibility and diagnostics
  • gateway startup/bootstrap with plugin metadata snapshots
  • public SDK compatibility for real external plugins
  • live-ish provider/channel probes only when safe credentials exist

First Checks

From the OpenClaw repo root:

bash
pnpm docs:list
git status --short --branch
pnpm changed:lanes --json

Follow openclaw-testing for dependency ownership and the choice of local or remote proof.

Runner Choice

Prefer this order:

  1. GitHub Package Acceptance for installable-package product proof.
  2. Current dedicated Linux worker for trusted source/package/Docker proof when it has the required dependencies and capabilities.
  3. ci-build-artifacts-testbox.yml Testbox when Docker/package lanes need seeded dist, dist-runtime, and package caches.
  4. ci-check-testbox.yml Testbox for source checks, targeted Vitest, package-boundary checks, or focused Docker lanes.
  5. Workstation targeted commands only for small format/static/unit probes.

Avoid long package Docker runs from a stale sparse worktree. If Testbox sync reports hundreds of changed files or starts deleting package inputs, stop and warm a fresh box from current main, or switch to Package Acceptance.

Existing Baseline

Run or verify these before inventing new coverage:

bash
OPENCLAW_TESTBOX=1 pnpm check:changed
pnpm run test:extensions:package-boundary:canary
pnpm run test:extensions:package-boundary:compile
pnpm test:docker:plugins
OPENCLAW_PLUGINS_E2E_CLAWHUB=0 pnpm test:docker:plugins
pnpm test:docker:plugin-update

For full bundled install/uninstall proof, shard the packaged sweep:

bash
OPENCLAW_BUNDLED_PLUGIN_SWEEP_TOTAL=8 \
OPENCLAW_BUNDLED_PLUGIN_SWEEP_INDEX=<0-7> \
pnpm test:docker:bundled-plugin-install-uninstall

This example partitions the selected package's plugin inventory over shards 0-7. Private QA plugins are source-mode only unless a package explicitly includes them.

Confidence Matrix

Use this matrix for pre-release signoff. Record pass/fail, run URL/Testbox ID, package SHA/version, and skipped-live reason.

SurfaceProofPreferred runner
Package artifactPackage Acceptance suite_profile=package or custom lanesGitHub Actions
Bundled lifecycleSharded test:docker:bundled-plugin-install-uninstallTestbox or release Docker
External pluginstest:docker:plugins and plugins-offlineTestbox/package acceptance
Update no-optest:docker:plugin-updateTestbox/package acceptance
Doctor/fixseeded bad configs + doctor --fix --non-interactivenew Docker/Testbox harness
Config round-tripconfig set/get, inspect, doctor, reload, diff hashnew Docker/Testbox harness
Gateway bootstrapclean HOME, plugin groups enabled/disabled, status JSONnew Docker/Testbox harness
SDK compatibilitydirectory, tgz, and file: external plugins using SDK subpathstest:docker:plugins plus new smoke
Live-ishredacted provider/channel probes only for present envTestbox live lanes

Package Acceptance Plan

Use this when validating a release branch, beta, or candidate package:

bash
gh workflow run package-acceptance.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f workflow_ref=main \
  -f source=ref \
  -f package_ref=<branch-or-sha> \
  -f suite_profile=custom \
  -f docker_lanes='plugins-offline plugin-update doctor-switch update-channel-switch config-reload mcp-channels npm-onboard-channel-agent' \
  -f telegram_mode=mock-openai

Use source=npm -f package_spec=openclaw@beta for published beta proof. Keep workflow_ref as trusted current harness code unless the release process says otherwise.

For extended-stable shared publication, require complete exact-target Full Release Validation from the trusted main-pinned release-ci/* harness. Direct canonical-branch or main producers do not satisfy the protected publisher. Package Acceptance is a post-publish selector smoke:

bash
gh workflow run package-acceptance.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f workflow_ref=main \
  -f source=npm \
  -f package_spec=openclaw@extended-stable \
  -f suite_profile=package \
  -f telegram_mode=mock-openai

Record the resolved version. Still verify every package and selector in the tag's all-publishable inventory; one smoke is not registry readback.

Plugin npm Artifact Preflight

Use the trusted main workflow to prepare and read back a selected plugin npm artifact from an exact release SHA without entering any publish approval, environment, secret, OIDC, npm mutation, or ClawHub mutation path:

bash
release_sha="$(git rev-parse origin/release/2026.7.1)"
gh workflow run plugin-npm-release.yml \
  --repo openclaw/openclaw \
  --ref main \
  -f preflight_only=true \
  -f publish_scope=selected \
  -f plugins=@openclaw/meta-provider \
  -f ref="${release_sha}" \
  -f npm_dist_tag=default

Do not pass release_publish_run_id. Require the workflow to finish verify_plugin_npm_preflight successfully. Record the run URL, workflow SHA, and source SHA. The workflow first creates the staging/readback artifact plugin-npm-package-source-<source-sha>-<extension-id> containing npm-pack.json, preflight-manifest.json, and the tarball. It then uploads the final consumer artifact plugin-npm-package-<extension-id>-<version>-<route>-<run-id>-<attempt> containing the tarball and plugin-publication-manifest.json.

Record the final artifact name and digest separately. The manifest uses openclaw.plugin-publication-artifact/v1 and records the target SHA, package manifest hashes, publication route and policy, and tarball hashes and inventory. This proof is validation-only; it does not authorize or stage publication. The separate trusted_publisher_preflight=true OIDC check requires a protected release-publish/<tooling-sha12>-<epoch> dispatch tag and runs in npm-publish. Real publication also requires that tooling tag; a direct human dispatch waits for its npm-release approval job before publishing. For an already-published version, require npm dist.integrity and dist.shasum to match the verified tarball. Treat only missing or provably older dist-tags as repairable; newer or incomparable selectors are a blocker.

New Testbox Harness Plan

If more certainty is needed, add or run a plugin-lifecycle-matrix Docker lane that uses one package tarball and sharded plugin lists. Per plugin:

  1. Start with a clean HOME.
  2. Capture plugins list --json.
  3. plugins install <id>.
  4. plugins inspect <id> --json.
  5. plugins disable <id>, then assert disabled visibility.
  6. plugins enable <id>, except config-required plugins without config.
  7. plugins registry --refresh.
  8. doctor --non-interactive.
  9. plugins uninstall <id> --force.
  10. Assert the plugin's plugins.entries value is exactly { enabled: false }, while its allow/deny entries, install record, managed directory, and bundled runtime load paths are gone. Use the existing harness's source-qualified uninstall expectations for historical targets.
  11. Assert diagnostics contain no level: "error" and output redacts secret-looking values.

Keep memory-lancedb special: it is config-required. First assert install does not enable it without embedding config, then run a second configured case.

Doctor/Fix Matrix

Seed bad states and require doctor --fix --non-interactive to repair them, then run doctor again and require idempotence:

  • stale plugins.allow
  • stale plugins.entries
  • stale channel config for missing channel plugin
  • invalid plugins.entries.<id>.config
  • packaged bundled path in plugins.load.paths
  • legacy plugins.installs
  • disabled channel/plugin config that must not stage runtime deps
  • root-owned global package tree that must remain unmodified

Gateway Bootstrap Matrix

Start packaged OpenClaw in Docker with clean state:

  • provider plugins enabled, no credentials: ready with warnings, no crash
  • channel plugins configured disabled: no runtime deps staged
  • startup-activation plugins enabled: ready and reflected in status
  • invalid single plugin config: bad plugin skipped/quarantined, others remain

Assert:

  • gateway reaches ready
  • openclaw status --json includes plugin diagnostics
  • openclaw plugins inspect --all --json is parseable
  • package tree is not mutated
  • logs contain no raw tokens

Config Round-Trip Representatives

Use representative plugin families instead of every plugin for deep config round-trip:

  • providers: openai, anthropic, mistral, openrouter
  • channels: telegram, discord, slack, whatsapp
  • memory: memory-lancedb
  • feature/runtime: browser, acpx, tokenjuice

For each representative:

  1. Write config through CLI when possible.
  2. Read it back through config get or JSON.
  3. Run plugins inspect.
  4. Run doctor --non-interactive.
  5. Trigger gateway config reload if applicable.
  6. Compare config hash before/after no-op commands.

External SDK Smoke

In a package Docker lane, create tiny external plugins and install them from:

  • local directory
  • .tgz
  • file: npm spec

Cover CJS and ESM shapes, plus at least one plugin importing focused openclaw/plugin-sdk/* subpaths. Assert plugins inspect sees its tool, gateway method, CLI command, or service.

Live-Ish Probe Rules

Before live-ish work, source allowed env in Testbox and generate a redacted availability matrix: present/missing only, never values.

Only run probes for credentials that exist. Prefer auth/catalog/status probes over sending user-visible messages. If a probe might contact an external user, channel, or workspace, stop and ask the user.

Reporting

Report in this shape:

text
package/ref:
tbx ids / run urls:
matrix:
  bundled lifecycle:
  package acceptance:
  doctor/fix:
  gateway bootstrap:
  config round-trip:
  sdk external:
  live-ish:
failures:
skips:
next highest-value gap:

Say clearly when a failure is Testbox sync/env damage rather than product behavior, and prove that with a clean rerun or current-main comparison.

Bundled files

The model reads these on demand while the skill is loaded. They are exposed as readable files and are never executed.

Frequently asked questions

What does the Release Openclaw Plugin Testing AI skill do?

Plan and run pre-release OpenClaw plugin validation across bundled plugins, package artifacts, lifecycle commands, doctor/fix, config round-trip, gateway startup, SDK compatibility, Docker E2E, Package Acceptance, and Testbox proof.

Why use Release Openclaw Plugin Testing on TypingMind?

Because you install it once and use it with any model. Release Openclaw Plugin Testing is plain Markdown rather than provider-specific code, so the same skill runs on GPT-5, Claude, Gemini, Grok, or a local model — and you can switch model mid-chat without it breaking. TypingMind runs on your own API keys, so you pay providers directly instead of a per-seat subscription, and your skills and chats stay in your own storage.

How do I install Release Openclaw Plugin Testing in TypingMind?

Open Plugins → Skills → Install from GitHub in TypingMind and paste https://github.com/openclaw/openclaw/tree/main/.agents/skills/release-openclaw-plugin-testing. TypingMind reads its SKILL.md and bundles its files and installs it as a skill you can enable per chat.

Which AI models can use Release Openclaw Plugin Testing?

Any model you connect in TypingMind. AI skills are plain Markdown instructions rather than provider-specific code, so GPT, Claude, Gemini, Grok, and local models can all load this skill when a request matches it.

How many AI models can I use with Release Openclaw Plugin Testing?

As many as you like. As long as a model supports skills, you can use Release Openclaw Plugin Testing with it — GPT, Claude, Gemini, Grok, DeepSeek, Mistral, Llama and more — all on TypingMind with your own API keys.

Is the Release Openclaw Plugin Testing AI skill free?

It is published on GitHub by openclaw. Check the repository for licensing terms. You only pay your own AI provider for the tokens you use.

What are AI skills?

An AI skill is a reusable instruction bundle that teaches an AI model how to do one specific task. It follows the open Agent Skills format: a SKILL.md file with a name and description, plus any scripts, templates or reference files the model may need. The model reads the instructions only when your request matches the skill, so an installed skill costs nothing until it is used.

How are AI skills different from plugins or MCP servers?

A plugin or MCP server gives a model new tools to call — code that runs somewhere and returns a result. An AI skill gives the model knowledge and process instead: how to approach a task, which steps to follow, what good output looks like. Skills are plain Markdown, so they need no server, no API key and no runtime, and they work with any model.

View all

Set up your own AI workspace now

Get notified about new features and future giveaways by subscribing to our newsletter 👇