skills/ghostscope-e2e-runner/SKILL.md
Run GhostScope e2e through the project runner service API, including explicit topology runs, with direct topology-aware `cargo test` only as a fallback when the runner is unavailable. Use when the user asks to execute e2e tests, run a specific test case, run tests for a specific repo path, diagnose e2e failures, handle sudo or permission issues around eBPF test execution, or run container-topology e2e scenarios.
npx skillsauth add swananan/ghostscope ghostscope-e2e-runnerInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Execute GhostScope e2e with the project-standard runner service and explicit topology requests.
Use scripts/e2e/runner/ for the HTTP runner service flow.
Use direct cargo test with sandbox environment variables only as a fallback when the runner service is unavailable or when the user explicitly asks for the raw CI-style commands.
This skill is the default path for both standard and container-topology GhostScope e2e execution.
Prefer the HTTP runner service path first, then fall back to local commands only when the service path is unavailable.
Use repository root /mnt/500g/code/ghostscope unless the user gives another path.
Start runner service (user can run with sudo when required):
./scripts/e2e/runner/start_e2e_runner_service.sh
Run one case through service:
curl -sS -X POST http://127.0.0.1:8788/runs \
-H 'Content-Type: application/json' \
-d '{
"sudo": true,
"repo": "/mnt/500g/code/ghostscope",
"test_case": "test_rust_script_print_globals"
}'
Run one case with explicit sandbox topology through the runner API:
curl -sS -X POST http://127.0.0.1:8788/runs \
-H 'Content-Type: application/json' \
-d '{
"sudo": true,
"repo": "/mnt/500g/code/ghostscope",
"test_case": "test_correct_pid_filtering",
"topology": {
"ghostscope": "host",
"target": "docker-private"
}
}'
Run one case with explicit topology and GhostScope debug logs through the runner API:
curl -sS -X POST http://127.0.0.1:8788/runs \
-H 'Content-Type: application/json' \
-d '{
"sudo": true,
"repo": "/mnt/500g/code/ghostscope",
"test_case": "test_correct_pid_filtering",
"logging": {
"level": "debug"
},
"topology": {
"ghostscope": "host",
"target": "docker-private"
}
}'
Run full e2e set (no case filter):
curl -sS -X POST http://127.0.0.1:8788/runs \
-H 'Content-Type: application/json' \
-d '{
"sudo": true,
"repo": "/mnt/500g/code/ghostscope"
}'
Run full e2e for the primary container topologies through the runner API:
curl -sS -X POST http://127.0.0.1:8788/runs \
-H 'Content-Type: application/json' \
-d '{
"sudo": true,
"repo": "/mnt/500g/code/ghostscope",
"topology": {
"ghostscope": "host",
"target": "docker-private"
}
}'
curl -sS -X POST http://127.0.0.1:8788/runs \
-H 'Content-Type: application/json' \
-d '{
"sudo": true,
"repo": "/mnt/500g/code/ghostscope",
"topology": {
"ghostscope": "docker-private",
"target": "docker-private",
"target_mode": "child-container"
}
}'
Run host-PID same-sandbox smoke through the runner API:
for test_case in test_invalid_pid_handling test_correct_pid_filtering test_pid_specificity_with_multiple_processes; do
curl -sS -X POST http://127.0.0.1:8788/runs \
-H 'Content-Type: application/json' \
-d "{
\"sudo\": true,
\"repo\": \"/mnt/500g/code/ghostscope\",
\"test_case\": \"$test_case\",
\"topology\": {
\"ghostscope\": \"docker-host\",
\"target\": \"docker-host\"
}
}"
done
Fallback local topology commands:
cargo build -p ghostscope -p dwarf-tool --all-features
sudo env \
E2E_GHOSTSCOPE_SANDBOX=host \
E2E_TARGET_SANDBOX=docker-private \
cargo test -p ghostscope-e2e-tests --tests --all-features -- --nocapture
sudo env \
E2E_GHOSTSCOPE_SANDBOX=docker-private \
E2E_TARGET_SANDBOX=docker-private \
cargo test -p ghostscope-e2e-tests --tests --all-features -- --nocapture
for test_case in test_invalid_pid_handling test_correct_pid_filtering test_pid_specificity_with_multiple_processes; do
sudo env \
E2E_GHOSTSCOPE_SANDBOX=docker-host \
E2E_TARGET_SANDBOX=docker-host \
cargo test -p ghostscope-e2e-tests --all-features --test script_execution "$test_case" -- --nocapture
done
Check service health:
curl -sS http://127.0.0.1:8788/health
host -> docker-private through the runner service API with topologydocker-private -> same docker-private through the runner service API with topologydocker-host -> same docker-host through the runner service API with topologysudo env ... cargo test only when the runner service is unavailable or when the user explicitly asks for the raw CI-style commands/health before submitting runs when the user expects service mode.POST /runs for standard host-host runs:repo when the checkout path is not the default repo.test_case when the user asks for a single case.sudo: true for eBPF tests that require elevated privileges.topology object:ghostscope: host|docker-private|docker-hosttarget: host|docker-private|docker-hosttarget_mode: same|child-container (use child-container only with docker-private -> docker-private)logging.level: error|warn|info|debug|tracetopology is omitted, the run defaults to host -> hostlogging.level is set, the e2e helper enables GhostScope file+console logging for that runIf output contains GhostScope needs elevated privileges to load eBPF programs:
E2E_SUDO=1.If output shows sudo: a password is required:
If output contains invalid repo path or missing Cargo.toml:
E2E_REPO_DIR or service DEFAULT_REPO_DIR.Use quick-reference.md for command templates and environment variables.
tools
Explain GhostScope and turn the project docs into concrete tracing commands, trace scripts, privilege setup, and issue-report workflows for source-aware runtime analysis. Use when the user asks how to install GhostScope, provide source tree and DWARF inputs, handle eBPF privileges, attach to a PID or binary, choose between `-p` and `-t`, inspect variables, write GhostScope trace scripts, use Input Mode commands, work through container or PID-namespace CLI scenarios, or triage GhostScope failures, crashes, and GitHub issue reports.
development
Maintainer-only workflow for handling GitHub Secret Scanning alerts on OpenClaw. Use when Codex needs to triage, redact, clean up, and resolve secret leakage found in issue comments, issue bodies, PR comments, or other GitHub content.
development
Maintainer workflow for OpenClaw releases, prereleases, changelog release notes, and publish validation. Use when Codex needs to prepare or verify stable or beta release steps, align version naming, assemble release notes, check release auth requirements, or validate publish-time commands and artifacts.
development
Run, watch, debug, and extend OpenClaw QA testing with qa-lab and qa-channel. Use when Codex needs to execute the repo-backed QA suite, inspect live QA artifacts, debug failing scenarios, add new QA scenarios, or explain the OpenClaw QA workflow. Prefer the live OpenAI lane with regular openai/gpt-5.4 in fast mode; do not use gpt-5.4-pro or gpt-5.4-mini unless the user explicitly overrides that policy.