$ ~/registry/skill/openclaw-agents-skills-openclaw-test-performance

SKILL

openclaw-test-performance

Name: openclaw-test-performance
Author: openclaw

Analyze and optimize OpenClaw test performance, memory use, and coverage slowdowns.

Stars

★ 382,582

Source

GitHub

Updated

2026-07-11

// securityLow risk

Prompt only, no code
Open source
Community-trusted· 377.5k

Summary

The material indicates a prompt/documentation-style performance skill with no required secrets, no declared remote endpoints, and no direct capability to execute code or exfiltrate data. Combined with its GitHub open-source origin and very strong community adoption, the overall risk is low.

CredentialsLow risk

The material explicitly states that no keys or environment variables are required, and it does not request API tokens, account credentials, or other sensitive authentication data; credential leakage or misuse risk is therefore low.

Network egressLow risk

No remote endpoints are declared. The content is mainly local test-performance guidance and command suggestions, with no indication that user data is sent to external services.

Code executionLow risk

The system flags it as prompt-only. Although the README mentions commands such as pnpm test and /usr/bin/time, the audited artifact itself provides guidance rather than an embedded agent or automatic local code-execution capability.

Data accessLow risk

The documentation suggests reading local AGENTS.md files and test files to locate performance issues, but the skill itself does not declare file write access, database access, or permissions beyond the stated performance-analysis purpose.

Supply chainLow risk

The source is a GitHub open-source repository with auditable code and extremely strong community adoption (~377k stars), which are strong positive signals. Although the license is not stated and maintenance status is unknown, the available material shows no red flags such as closed-source distribution, abandonment, or suspicious packaging.

Recommendations

Treat it as performance-analysis documentation and do not automatically execute README commands without review.
If you run the suggested test commands, first verify the arguments and file scope in an isolated development environment.
Before adopting it, review recent commits, release history, and license details of the repository.
If scripts, CI integration, or extra dependencies are introduced later, reassess code-execution and supply-chain risk.

Audited by: gpt-5.4 · 2026-06-17

// install

Copy the install command and let the AI configure it · recommended for beginners

Please install the "openclaw-test-performance" skill from askskill:
1. Download https://raw.githubusercontent.com/openclaw/openclaw/main/.agents/skills/openclaw-test-performance/SKILL.md
2. Save it as ~/.claude/skills/openclaw-test-performance/SKILL.md
3. Reload skills and tell me it's ready

// download

Download SKILL.mdInstall manifest ↗

// examples

Find why tests became slow

Prompt

Benchmark OpenClaw test and plugin-suite runs, compare the latest two executions, identify the slowest cases, the most expensive import chains, and coverage-related slow paths, then provide actionable optimization recommendations.

Expected

A performance comparison report with major bottlenecks, likely root causes, and prioritized optimization recommendations.

Investigate memory and heap growth

Prompt

Analyze CPU, RSS, and heap growth during OpenClaw test execution, identify possible memory leaks, high-allocation hotspots, or abnormal resource usage, and explain how to validate the findings.

Expected

A resource-usage analysis highlighting suspicious leak points or hotspot modules, plus validation and remediation steps.

Optimize coverage execution paths

Prompt

Inspect OpenClaw slow paths when coverage is enabled, analyze which files, imports, or plugins significantly slow the coverage phase, and propose refactoring or configuration changes to reduce overhead.

Expected

A list of slow coverage paths, impact assessment, and practical configuration or code optimization suggestions.

// docs

OpenClaw Test Performance

Use evidence first. The goal is real pnpm test, plugin-suite, and plugin-inspector speed/RSS improvement with coverage intact, not runner tuning by guesswork.

Workflow

Read the relevant local AGENTS.md files before editing:
- src/agents/AGENTS.md for agent/import hotspots.
- src/channels/AGENTS.md and src/plugins/AGENTS.md for plugin/channel laziness.
- src/gateway/AGENTS.md for server lifecycle tests.
- test/helpers/AGENTS.md and test/helpers/channels/AGENTS.md for shared contract helpers.
- src/infra/outbound/AGENTS.md for outbound/media/action tests.
Establish a baseline before changing code:
- Prefer pnpm test:perf:groups --full-suite --allow-failures --output <file> for full-suite ranking.
- For bundled plugin breadth, run the smallest relevant pnpm test:extensions:batch <plugin[,plugin...]> or plugin-inspector command before jumping to the full extension sweep.
- For a scoped hotspot use: /usr/bin/time -l pnpm test <file-or-files> --maxWorkers=1 --reporter=verbose
- For import-heavy suspicion add: OPENCLAW_VITEST_IMPORT_DURATIONS=1 OPENCLAW_VITEST_PRINT_IMPORT_BREAKDOWN=1.
Separate wall/runner noise from real file cost:
- Compare Vitest duration, test body timing, import breakdown, wall time, and max RSS.
- Re-run single files when grouped/full-suite numbers look stale or noisy.
- If a full-suite grouped run reports a lane failure but JSON says tests passed, capture that as harness/noise and verify the suspect file directly.
Pick the next attack by return and risk:
- High return: one file/test dominates seconds or RSS and has a clear root.
- High leverage: one plugin or SDK barrel causes every plugin-inspector or extension-batch run to load broad runtime.
- Lower risk: static descriptors, target parsing, routing, auth bypass, setup hints, registry fixtures, or test server lifecycle.
- Higher risk: real memory/runtime behavior, live providers, protocol contracts, or broad production refactors.
Fix the root cause, not the symptom:
- Move static metadata/parsing into narrow helpers or lightweight artifacts reused by full runtime and fast paths.
- Prefer dependency injection, loaded-plugin-only lookup, explicit fixtures, and pure helpers over broad mocks.
- Reuse suite-level servers/clients when a fresh handshake is irrelevant.
- Keep schedulers/background loops off unless the test proves scheduling.
- In plugin paths, move static metadata into manifest/lightweight artifacts and keep runtime plugin loads behind explicit execution boundaries.
Preserve coverage shape:
- Do not delete a slow integration proof unless the exact production composition is extracted into a named helper and tested.
- Keep one cheap integration smoke when cross-component wiring matters.
- State explicitly what incidental coverage was removed, if any.
Re-benchmark the same command after the change and compute seconds plus percent gain.
Update the running report when requested or when this thread is tracking one. Include before/after commands, artifacts, coverage notes, verification, and next attack order.
Commit with scripts/committer "<message>" <paths...> and push when the user asked for commits/pushes. Stage only files touched for this attack.

Plugin-Suite Workflow

Use this section when perf work involves bundled plugins, plugin-inspector, SDK barrels, package-boundary tests, or extension suites.

Map the suite shape first:
- source tests: pnpm test extensions/<id> or pnpm test:extensions:batch <id>
- package boundaries: pnpm run test:extensions:package-boundary:canary and pnpm run test:extensions:package-boundary:compile
- all bundled source tests: pnpm test:extensions

…

View full docs ↗

Refactor OpenClaw docs pages with source-checked preservation, clearer structure, and verification.

openclawGet→

$ loading_

Please install the "openclaw-test-performance" skill from askskill: 1. Download https://raw.githubusercontent.com/openclaw/openclaw/main/.agents/skills/openclaw-test-performance/SKILL.md 2. Save it as ~/.claude/skills/openclaw-test-performance/SKILL.md 3. Reload skills and tell me it's ready

// examples

Find why tests became slow

Prompt

Benchmark OpenClaw test and plugin-suite runs, compare the latest two executions, identify the slowest cases, the most expensive import chains, and coverage-related slow paths, then provide actionable optimization recommendations.

Expected

A performance comparison report with major bottlenecks, likely root causes, and prioritized optimization recommendations.

Investigate memory and heap growth

Prompt

Analyze CPU, RSS, and heap growth during OpenClaw test execution, identify possible memory leaks, high-allocation hotspots, or abnormal resource usage, and explain how to validate the findings.

Expected

A resource-usage analysis highlighting suspicious leak points or hotspot modules, plus validation and remediation steps.

Optimize coverage execution paths

Prompt

Inspect OpenClaw slow paths when coverage is enabled, analyze which files, imports, or plugins significantly slow the coverage phase, and propose refactoring or configuration changes to reduce overhead.

Expected

A list of slow coverage paths, impact assessment, and practical configuration or code optimization suggestions.

// docs

OpenClaw Test Performance

Use evidence first. The goal is real pnpm test, plugin-suite, and plugin-inspector speed/RSS improvement with coverage intact, not runner tuning by guesswork.

Workflow

Read the relevant local AGENTS.md files before editing:
- src/agents/AGENTS.md for agent/import hotspots.
- src/channels/AGENTS.md and src/plugins/AGENTS.md for plugin/channel laziness.
- src/gateway/AGENTS.md for server lifecycle tests.
- test/helpers/AGENTS.md and test/helpers/channels/AGENTS.md for shared contract helpers.
- src/infra/outbound/AGENTS.md for outbound/media/action tests.
Establish a baseline before changing code:
- Prefer pnpm test:perf:groups --full-suite --allow-failures --output <file> for full-suite ranking.
- For bundled plugin breadth, run the smallest relevant pnpm test:extensions:batch <plugin[,plugin...]> or plugin-inspector command before jumping to the full extension sweep.
- For a scoped hotspot use: /usr/bin/time -l pnpm test <file-or-files> --maxWorkers=1 --reporter=verbose
- For import-heavy suspicion add: OPENCLAW_VITEST_IMPORT_DURATIONS=1 OPENCLAW_VITEST_PRINT_IMPORT_BREAKDOWN=1.
Separate wall/runner noise from real file cost:
- Compare Vitest duration, test body timing, import breakdown, wall time, and max RSS.
- Re-run single files when grouped/full-suite numbers look stale or noisy.
- If a full-suite grouped run reports a lane failure but JSON says tests passed, capture that as harness/noise and verify the suspect file directly.
Pick the next attack by return and risk:
- High return: one file/test dominates seconds or RSS and has a clear root.
- High leverage: one plugin or SDK barrel causes every plugin-inspector or extension-batch run to load broad runtime.
- Lower risk: static descriptors, target parsing, routing, auth bypass, setup hints, registry fixtures, or test server lifecycle.
- Higher risk: real memory/runtime behavior, live providers, protocol contracts, or broad production refactors.
Fix the root cause, not the symptom:
- Move static metadata/parsing into narrow helpers or lightweight artifacts reused by full runtime and fast paths.
- Prefer dependency injection, loaded-plugin-only lookup, explicit fixtures, and pure helpers over broad mocks.
- Reuse suite-level servers/clients when a fresh handshake is irrelevant.
- Keep schedulers/background loops off unless the test proves scheduling.
- In plugin paths, move static metadata into manifest/lightweight artifacts and keep runtime plugin loads behind explicit execution boundaries.
Preserve coverage shape:
- Do not delete a slow integration proof unless the exact production composition is extracted into a named helper and tested.
- Keep one cheap integration smoke when cross-component wiring matters.
- State explicitly what incidental coverage was removed, if any.
Re-benchmark the same command after the change and compute seconds plus percent gain.
Update the running report when requested or when this thread is tracking one. Include before/after commands, artifacts, coverage notes, verification, and next attack order.
Commit with scripts/committer "<message>" <paths...> and push when the user asked for commits/pushes. Stage only files touched for this attack.

Plugin-Suite Workflow

Use this section when perf work involves bundled plugins, plugin-inspector, SDK barrels, package-boundary tests, or extension suites.

Map the suite shape first:
- source tests: pnpm test extensions/<id> or pnpm test:extensions:batch <id>
- package boundaries: pnpm run test:extensions:package-boundary:canary and pnpm run test:extensions:package-boundary:compile
- all bundled source tests: pnpm test:extensions

…

View full docs ↗