菜单
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.
用 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 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 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 | inspect-workflow |
| description | 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. |
Pulls workflow definition and recent execution state from the runtime API (port 7001).
By name (substring search):
curl -s "http://127.0.0.1:7001/api/runtime/workflows?search=<name>&pageSize=20" \
| jq '.items[] | {id, name, path, currentVersion, updatedAt}'
By folder path:
curl -s "http://127.0.0.1:7001/api/runtime/workflows?path=<folder>&recursive=true&pageSize=100" \
| jq '.items[] | {id, name, path}'
List everything:
curl -s "http://127.0.0.1:7001/api/runtime/workflows?pageSize=100" | jq '.items | length'
Latest version:
curl -s "http://127.0.0.1:7001/api/runtime/workflows/<WORKFLOW_ID>" \
| jq '{id, name, currentVersion, definition, inputSchema, outputSchema}'
A specific version:
curl -s "http://127.0.0.1:7001/api/runtime/workflows/<WORKFLOW_ID>?versionNumber=3" | jq .
For just the step graph:
curl -s "http://127.0.0.1:7001/api/runtime/workflows/<WORKFLOW_ID>" \
| jq '.definition.steps[] | {id, type, name}'
curl -s "http://127.0.0.1:7001/api/runtime/workflows/<WORKFLOW_ID>/instances?page=0&size=20" \
| jq '.items[] | {id, status, startedAt, durationMs, error: .error.message}'
For status breakdown:
curl -s "http://127.0.0.1:7001/api/runtime/workflows/<WORKFLOW_ID>/instances?size=100" \
| jq -r '.items[].status' | sort | uniq -c
For only failures:
curl -s "http://127.0.0.1:7001/api/runtime/workflows/<WORKFLOW_ID>/instances?size=50" \
| jq '.items[] | select(.status=="failed") | {id, startedAt, error: .error.message}'
Then drill into a specific failure with the trace-instance skill.
# extract integration_ids referenced by Agent steps
curl -s "http://127.0.0.1:7001/api/runtime/workflows/<WORKFLOW_ID>" \
| jq -r '.definition.steps[] | select(.type=="Agent") | .config.connectionId // empty' \
| sort -u
For each connection ID, see the inspect-connection skill.
"Workflow not appearing in the list" → version probably hasn't been registered. Re-run the compile + register flow from e2e-verify step 5–6.
"Steps in the picker don't match what I see in the definition" → frontend client may be stale; re-run regen-frontend-api.
"All instances suddenly failing the same way" → check whether anything changed in: a connection (token expired — inspect-connection), an agent (rebuild + re-register), or a downstream service (out-of-band).