菜单
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.
用 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 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.
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 | tail-logs |
| description | 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. |
Server logs are the source of truth for the runtime / WASM runner / DB layer. Default RUST_LOG=info is usually too noisy and debug is too much; this skill picks the right slice.
The server respects per-crate RUST_LOG directives. Common slices:
RUST_LOG="runtara_server=info,runtara_environment=info,runtara_core=info"
RUST_LOG="runtara_environment=debug,runtara_agents=debug,runtara_workflows=info,runtara_server=warn"
runtara_agents=debug shows the per-capability inputs/outputs. runtara_environment=debug shows the WASM runner lifecycle.
RUST_LOG="runtara_connections=debug,runtara_server=info,hyper=warn"
Use when token refresh or OAuth callback isn't behaving. Mute hyper or it floods.
RUST_LOG="runtara_dsl=debug,runtara_compile=debug,runtara_workflows=info"
Useful when a step type isn't being picked up or schema generation is off.
RUST_LOG="sqlx=info,runtara_server=debug"
sqlx=info shows applied migrations; bump to debug to see every query (very noisy).
If the server is already running, restart it with the new RUST_LOG — it's read once at startup, not per-request:
# kill the previous instance
pkill -x runtara-server
# relaunch with the focused filter (full env block from e2e-verify)
RUST_LOG="runtara_environment=debug,runtara_agents=debug,runtara_workflows=info,runtara_server=warn" \
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 2>&1 | tee /tmp/runtara-server.log
If you tee'd to a file (recommended), tail with grep:
# scope to a specific instance
tail -f /tmp/runtara-server.log | grep --line-buffered "<INSTANCE_ID>"
# scope to a specific tenant
tail -f /tmp/runtara-server.log | grep --line-buffered 'tenant_id=<TENANT>'
# show only WARN+ across crates
tail -f /tmp/runtara-server.log | grep --line-buffered -E ' (WARN|ERROR) '
info, drop to warn for crates you trust, bump to debug only for the suspect crate.RUST_LOG=trace,* everywhere — it'll hide the signal in volume.trace-instance), the logs almost always tell you the cause first; check there before adding more API calls.