菜单
Use when local dev state has drifted into a weird shape — failing migrations, half-applied schema changes, stale cached binaries, suspended instances clogging the system. Wipes the e2e DBs and data dir and gives you a clean slate. Distinct from e2e-verify which assumes a clean env.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use to verify changes to agents, capabilities, integrations, steps, or runtime end-to-end before declaring a task done. Boots the full server stack with embedded WASM runner and separate DBs, then drives the server HTTP API to create, compile, and execute a workflow and assert observable behavior. Unit tests are not sufficient — agent/runtime changes must e2e-verify.
Use to set up the right RUST_LOG filters and tail server + environment logs scoped to a specific tenant, instance, or component. Saves the "what's the right log filter again" lookup. Pair with trace-instance when you need both API state and live log output.
Use when a workflow that uses a connection misbehaves — to see stored params (secrets masked), token state, rate-limit history, and which integration it belongs to. Catches stale OAuth tokens and misconfigured connection params before you blame the agent.
Use to get a quick health view of a workflow — its definition, registered versions, recent instances and their statuses, and which connections it touches. The "is this thing healthy / what does it look like right now" view, distinct from trace-instance which drills into one specific run.
Use for the tight inner loop when developing or debugging a single capability — rebuild only the changed crate, recompile a small test workflow that exercises it, register, run, dump output. ~10s feedback vs full e2e-verify. Use e2e-verify for the final pre-commit check; use this while iterating.
Use to debug a specific workflow instance — walks through input envelope, per-step state, step inputs/outputs, errors, and final result. Pulls everything from the runtime API (port 7001), no DB queries. The default skill when "this run did something weird and I need to know why".
| name | reset-local-env |
| description | Use when local dev state has drifted into a weird shape — failing migrations, half-applied schema changes, stale cached binaries, suspended instances clogging the system. Wipes the e2e DBs and data dir and gives you a clean slate. Distinct from e2e-verify which assumes a clean env. |
For when "the migrations look applied but a fresh column is missing" or "I have 200 suspended instances from yesterday's SIGTERM tests" or "wasm runner cache is acting weird".
This skill is destructive — it deletes the e2e databases and data dir. It does not touch your prod / dev DBs unless you point it at them.
Confirm what you're about to wipe:
DB_URL="postgres://user:pass@localhost:5432/postgres"
psql "$DB_URL" -c "SELECT datname FROM pg_database WHERE datname LIKE 'runtara_e2e%';"
ls -la /tmp/runtara_e2e_data 2>/dev/null
If those names don't match what your local server uses, stop and adjust the env variables below before running.
pkill -x runtara-server
# wait for it to exit cleanly
while pgrep -x runtara-server > /dev/null; do sleep 0.5; done
The two databases must be reset together — the server and environment migrations are versioned independently and a partial reset leaves them out of sync (manifests as migration was previously applied but is missing).
DB_URL="postgres://user:pass@localhost:5432/postgres"
psql "$DB_URL" -c "DROP DATABASE IF EXISTS runtara_e2e_test;"
psql "$DB_URL" -c "DROP DATABASE IF EXISTS runtara_e2e_server;"
psql "$DB_URL" -c "CREATE DATABASE runtara_e2e_test;"
psql "$DB_URL" -c "CREATE DATABASE runtara_e2e_server;"
rm -rf /tmp/runtara_e2e_data
mkdir -p /tmp/runtara_e2e_data
If you suspect stale compiled stdlib (rare — usually only after a stdlib bump):
rm -rf target/native_cache_wasm target/wasm32-wasip2
Then rebuild from e2e-verify step 1.
The server runs migrations on startup, so a fresh DB will be populated automatically. Use the env block from e2e-verify step 4.
RUST_LOG="sqlx=info,runtara_server=info" \
RUNTARA_SERVER_DATABASE_URL="postgres://user:pass@localhost:5432/runtara_e2e_server" \
OBJECT_MODEL_DATABASE_URL="postgres://user:pass@localhost:5432/runtara_e2e_server" \
RUNTARA_DATABASE_URL="postgres://user:pass@localhost:5432/runtara_e2e_test" \
RUNTARA_ENVIRONMENT_ADDR="127.0.0.1:18002" \
DATA_DIR="/tmp/runtara_e2e_data" \
SERVER_PORT=17001 \
INTERNAL_PORT=17002 \
target/debug/runtara-server &
curl --retry 20 --retry-delay 1 --retry-connrefused http://127.0.0.1:8004/api/v1/health
sqlx=info confirms migrations applied cleanly. If a migration fails, fix it (see add-migration skill) before continuing — running e2e-verify against a half-migrated DB wastes time.
trace-instance to diagnose first./api/v1/images/{id} instead of dropping the DB.Workflows, instances, connections, and registered images are all gone. Re-register what you need via e2e-verify step 5–6 or the UI.