FreePublished on GitHubEnglish overview

openclaw-docker-e2e-authoring

Create and update OpenClaw end-to-end tests in Docker, checking complete workflows. Use fake servers to verify requests and real providers to check service behavior, including image understanding and the final text users receive.

OriginalShow the original description

Author OpenClaw Docker E2E and live provider Docker lanes.

openclaw/openclaw

Works withDocker

AI rating80/ 100 See how to install

Good for

Adding or updating Docker end-to-end tests
Checking payloads sent to dependencies
Verifying behavior with real model providers
Testing image understanding without answer leaks
Checking final user-visible chat responses

Overview

What it does

Creates and modifies end-to-end tests for OpenClaw in Docker, checking a workflow from its initial action through the final result. Tests using fake servers record requests sent across service boundaries and verify the actual outgoing content. When behavior depends on the real service, it combines these checks with tests using real credentials and models. Package scripts and test scenario registration are included in the same change.

When it helps

Use it when adding a Docker test path or checking behavior for a release. For image understanding tests, it addresses designs that prevent filenames or metadata from revealing the expected answer. For chat tests, it waits for processing to finish and checks the final text visible to the user.

Example requests

“Add a Docker test that checks outgoing requests with a fake server.”
“Create a test that checks image understanding with a real model.”
“Verify the final response after chat.send finishes.”

Notes

An OpenClaw development environment, Docker, and tools such as pnpm are required. Tests using real services also need the corresponding credentials and models. The workflow runs syntax checks and tests appropriate to the changes, followed by $autoreview before a commit or PR.

This overview was written by AI (OpenAI Codex) from the public SKILL.md. Check the original below for the exact behavior.

Objective evaluation

AI rated this skill on four points using only the contents of its SKILL.md. Stars and popularity are not taken into account.

Clear instructionsIs it clear when to use it and what it does?: AGoodIt identifies Docker test additions and changes as use cases and explains when to use fake dependencies or real services.
Concrete stepsAre steps, inputs, outputs, and examples spelled out?: AGoodIt specifies JSONL request logs, chat.send assertions, and commands for syntax checks and tests.
SafetyAre sending data, deleting files, and running commands disclosed?: BPartly lackingIt uses real credentials with external services but does not fully specify transmitted content or confirmation before execution.
Easy setupDoes it need few tools or API keys, and are they documented?: BPartly lackingDocker, pnpm, and real-service credentials are prerequisites, but environment setup instructions are absent.

The total counts each point as A = 25, B = 15, C = 5. Rated by AI (OpenAI Codex) as of Oct 19, 2026. Treat it as a guide and read the original before installing.

Disagree? Request a re-evaluation

Files included (1)

SKILL.md2.3 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

OpenClaw Docker E2E Authoring

Use this when adding or changing Docker E2E lanes, release-path Docker tests, or live-provider Docker proof.

Lane Choice

Deterministic Docker: fake the dependency/server and assert the exact runtime contract crossing the boundary.
Live Docker: use real provider credentials/model only when user-visible behavior needs the real service.
Prefer both when they prove different risks: deterministic for byte/payload routing, live for actual provider behavior.

Authoring Rules

Test-only helpers live in test/helpers or scripts/e2e/lib/<lane>/, not src/**, unless production imports them.
Package-installed app runs from /app; mount only explicit harness/helper paths read-only.
Fake servers should log boundary requests as JSONL and clients should assert the real dependency payload, not just process success.
Add the package script and scripts/lib/docker-e2e-scenarios.mjs lane in the same change.
If a lane installs a plugin from npm, default the spec via env so published and local override paths are both testable.

Media And Vision

Expected answer must exist only in pixels or provider output being tested.
Use neutral filenames, neutral prompts, and no metadata leaks.
Random bitmap/OCR tokens reuse the repo OCR-safe alphabet 24567ACEF unless the test owns a stronger glyph set.
Make the expected answer unique per run when proving real image understanding.

`chat.send` E2E

Require chat.send to return status: "started" and a string runId.
Wait for completion with agent.wait.
Assert final user-visible text via chat.history when event ordering is not the behavior under test.
Keep originating channel/account metadata only when the bug path needs queued inbound/channel context.

Verification

Run the smallest proof that covers the touched lane:

pnpm exec oxfmt --write <changed files>
node --check <new .mjs files>
bash -n <new .sh files>
node scripts/run-vitest.mjs test/scripts/docker-e2e-plan.test.ts
OPENCLAW_SKIP_DOCKER_BUILD=1 pnpm test:docker:<lane>

For real-provider lanes, run the matching live Docker script after deterministic Docker is green. Finish with $autoreview before commit/PR.

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

More skills from this repository

1password

FreeSummaryAI rating 100

Set up and authenticate the 1Password CLI, then supply stored passwords and API keys to commands or configuration. The skill covers desktop integration, service accounts, and interactive sign-in while keeping secrets out of chat and logs.

Setting up the 1Password CLI
Supplying API keys to commands
Using service account authentication in CI