openclaw-testing

Selects and runs the cheapest targeted OpenClaw test, CI, or Docker verification path.

Updated Jun 19, 2026
One-click install
npx skills add https://github.com/AmirulAndalib/Vilvona-AI --skill openclaw-testing-amirulandalib
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: openclaw-testing
Source: https://github.com/AmirulAndalib/Vilvona-AI/tree/main/.agents/skills/openclaw-testing
Command: npx skills add https://github.com/AmirulAndalib/Vilvona-AI --skill openclaw-testing-amirulandalib

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Running the full OpenClaw test suite for every change wastes hours of CI and local time. This Skill helps you classify a diff, pick the narrowest safe verification path, debug CI failures, and rerun only the lanes that matter. ## Core Features & Use Cases - Targeted Test Selection: Classifies the touched surface and routes to pnpm test:changed, pnpm check:changed, or single-file Vitest runs instead of the full suite. - CI and Release Debugging: Guides inspection of GitHub Actions runs, release validation umbrellas, Package Acceptance workflows, and Docker E2E lanes with cheap targeted reruns. - Worktree-Safe Execution: Provides safe commands for Codex worktrees and sparse checkouts using node scripts/run-vitest.mjs and the Crabbox wrapper for remote proof. - Use Case: After fixing a failing Docker lane, use pnpm test:docker:rerun <run-id> to derive the smallest rerun command instead of re-triggering the entire release validation workflow. ## Quick Start Ask the assistant to determine the cheapest safe way to verify your current OpenClaw change and run only the relevant tests or CI lanes.

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 targeted Vitest runs or `pnpm check:changed` for typecheck and lint. For a single failing file, use `pnpm test <path> -- --reporter=verbose`.

How do I rerun a failed Docker E2E lane without the full release path?

Use `pnpm test:docker:rerun <github-run-id>` to derive the smallest rerun command from the run's summary and failures artifacts. It prints a combined targeted workflow dispatch using the reusable live/E2E workflow with a `docker_lanes` list.

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

No. In linked or sparse checkouts, pnpm may trigger 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 instead.

What is the difference between pnpm check, pnpm test, and pnpm verify?

`pnpm check` runs typecheck, lint, and guards without Vitest. `pnpm test` runs the Vitest suite. `pnpm verify` runs check first, then the full test suite, with Crabbox phase markers so remote summaries show which half failed.

When should I run the Full Release Validation workflow?

Run it only when validating an actual release candidate, after broad shared CI or release orchestration changes, or when explicitly asked. For focused fixes, dispatch the matching `rerun_group` and rerun only the parent verifier job instead.

Why should I avoid running the full test suite for every change?

Full suites and local Docker lanes are expensive and slow. The default rule is to prove the touched surface first with targeted lanes, then broaden only when the changed contract genuinely requires wider coverage.