openclaw-testing

Selects and runs the cheapest targeted OpenClaw test, CI, Docker, or release validation lane.

1|Updated Jun 9, 2026
One-click install
npx skills add https://github.com/JEROME-PRAKASH-L/openclaw --skill openclaw-testing-jerome-prakash-l
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: openclaw-testing
Source: https://github.com/JEROME-PRAKASH-L/openclaw/tree/main/.agents/skills/openclaw-testing
Command: npx skills add https://github.com/JEROME-PRAKASH-L/openclaw --skill openclaw-testing-jerome-prakash-l

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Running the full OpenClaw test suite or release validation for every small change wastes hours of CI time and local compute. This Skill helps you pick the narrowest safe verification path for a given diff, debug failing CI jobs, and rerun only the lanes that matter. ## Core Features & Use Cases - Targeted Test Selection: Classify a diff and choose between pnpm test:changed, pnpm check:changed, single-file Vitest runs, or the node-based run-vitest.mjs harness for Codex worktrees. - CI and Release Debugging: Inspect GitHub Actions runs with gh, dispatch Full Release Validation, Release Checks, Package Acceptance, or reusable Live/E2E workflows with narrow rerun groups and lane filters. - Docker E2E Cost Control: Dry-run the Docker lane scheduler, derive cheap targeted reruns from summary.json/failures.json artifacts, and reuse prepared GHCR images and package tarballs. - Use Case: After fixing a single failing live E2E shard, dispatch the reusable workflow with rerun_group=live-e2e and a live_suite_filter instead of restarting the entire release umbrella. ## Quick Start Ask the assistant to determine the cheapest safe way to verify your current OpenClaw diff and rerun only the failing CI lane.

Frequently Asked Questions about openclaw-testing

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I run only the tests affected by my OpenClaw change?

Run `pnpm changed:lanes --json` to see which check lanes the diff touches, then use `pnpm test:changed` for cheap changed Vitest targets or `pnpm check:changed` for typecheck and lint. For one failing file, run `pnpm test <path> -- --reporter=verbose`.

How do I rerun a single failed Docker E2E lane in CI?

Use `pnpm test:docker:rerun <github-run-id>` to derive a targeted command from the run's summary.json and failures.json artifacts. It produces a reusable workflow dispatch with a `docker_lanes` list that reuses prepared GHCR images and the package tarball.

Can I run pnpm test inside a Codex worktree or sparse checkout?

No, direct `pnpm test` or `pnpm check` in a Codex worktree risks triggering dependency reconciliation or reinstalls. Use `node scripts/run-vitest.mjs <path>` for small local proof and `node scripts/crabbox-wrapper.mjs` for remote Testbox or AWS proof.

When should I use Full Release Validation versus Release Checks?

Full Release Validation is the manual umbrella that dispatches CI, Plugin Prerelease, and Release Checks, intended for actual release candidates. OpenClaw Release Checks is narrower, covering install smoke, cross-OS, live/E2E, and package lanes without the full normal CI child.

Why should I avoid running the full pnpm test suite locally?

The full suite and full Docker lanes are expensive and usually unnecessary for a focused diff. The Skill's default rule is to prove only the touched surface first, then broaden only when the changed contract genuinely demands it.