Skip to main content

run-workflow

Test and debug Sim workflows through the sim CLI using manual runs, trigger payloads, run-from-block, selected outputs, and run records. Use after authoring or when diagnosing execution; not for graph edits or deployment changes.

소스 정보

저장소
simstudioai/skills
최근 소스 활동
2026년 9월 29일 20:18
감지된 SKILL.md 언어
영어
스타
1
포크
1

설치 방법

기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.

소스 파일 검토

설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.

SKILL.md 표시 중

SKILL.md
소스 지침 · 읽기 전용 미리보기
name
run-workflow
description
Test and debug Sim workflows through the sim CLI using manual runs, trigger payloads, run-from-block, selected outputs, and run records. Use after authoring or when diagnosing execution; not for graph edits or deployment changes.
# Run a Sim Workflow Choose the execution mode that answers the user's question, then verify the terminal result rather than treating request acceptance as success. ## Choose saved state or deployment - Use `sim --output json workflows run <workflowId>` to run the active deployment. - Add `--manual` to run the current saved draft without deploying it. Manual execution and run-from-block require a personal API-key profile; a workspace API key is not permitted. - Do not deploy a draft merely to test it. A workflow does not need a Start block for a plain manual run: ```bash sim --output json workflows run <workflowId> --manual --input @input.json ``` To enter through a runnable trigger, use its block id and provide either explicit input or its server-derived mock payload: ```bash sim --output json workflows run <workflowId> \ --manual --trigger <triggerBlockId> --mock-payload ``` Do not combine `--mock-payload` with `--input`. Do not add `--async` to a manual run. ## Run from a block Run-from-block resumes a saved draft at one block using persisted upstream state from an exact prior run: ```bash sim --output json workflows run <workflowId> \ --from-block <blockId> --source-run <runId> ``` Do not guess a source run or synthesize upstream outputs. Confirm that the source run belongs to the workflow and contains the state the selected block needs. ## Long runs and uncertain responses Current CLI and server versions use heartbeat responses for ordinary synchronous runs, including `--manual`. A long-running draft does not require deployment. Use `--follow` when live progress helps; it does not make execution asynchronous. For an intended deployed run, use `--async` and `workflows runs wait <runId> --workflow <workflowId> --wait-timeout 3600`, or another explicit bound. After a timeout or connection loss, inspect the known run before starting another execution; external actions may already have occurred. Ordinary runs without `--follow` accept `--run-id` to choose the identifier before sending. It is not an idempotency key: a claimed ID conflicts rather than replaying the result, and a missing run record does not prove nothing executed. Do not automatically retry with a fresh or omitted ID. ## Keep output focused - Use repeated `--select-output <blockName.field>` values when only specific outputs matter. - Use `--follow` for a synchronous live run. Add `--include-thinking` or `--include-tool-calls` only when the user needs those diagnostics. - Use `--async` only for deployed runs that should return immediately. Then wait with `workflows runs wait` or inspect with `workflows runs get`; do not poll without a stopping bound. - Check `sim logs get --help` before using optional diagnostic flags. When it lists `--no-include-workflow-state`, use that flag to omit the saved graph from a log read. The trace still loads; use selected-output reads when only particular results matter. ## Diagnose failures 1. Read the returned run id, status, error, and selected outputs. 2. Inspect the run with `sim --output json workflows runs get <runId> --workflow <workflowId> --include-output`. 3. Read the workflow state and confirm the failing block's current inputs and connections. 4. Correct the graph with the build skill. Do not hide a deterministic failure behind retries or a different execution mode. Request acceptance, workflow completion, and successful tool results are different outcomes. A workflow can complete after handling a failed tool call. Inspect nested tool errors and the actual output before concluding that research or delivery succeeded; an absent trace is not proof of success. Four properties of runs and run records that mislead diagnosis when unknown: - A run record has a lifecycle. `logs get` returns NOT_FOUND for a run that is still in flight and for one that was cancelled, and a completed run can report a `redacting` status for a minute or two before its content is readable. Poll with a bounded retry before concluding the run vanished. - Firing a run immediately after `workflows deploy` reports the new version active can still execute the previous deployment, silently. When a run exists to verify a deploy, confirm the executed behavior from its outputs rather than trusting the deploy response, and re-run if the outputs match the old version. - Run traces nest: a child workflow's blocks appear inside its parent span, not at the top level. Reading only the top level of the span tree silently drops every block a child workflow ran, which can be most of the run. Walk the tree recursively before counting blocks or hunting the failing one, and judge the block-level trace rather than the wrapper status. - Cost comes in two units. The CLI's `logs get` reports `cost.total` in dollars, while the in-workflow logs block reports the same run's cost in credits. Never compare or store the two as one number. ## `{{KEY}}` in run output is usually a mask, not a failure Only `workflows runs get` and `logs get` return the masked copy, where a resolved secret is written back as `{{KEY}}` - or `[REDACTED_SECRET]` when it cannot be pinned to one name. Live run output is never masked: a plain run and a `--follow` stream hit the same endpoint and both carry real values, so never quote either back. So a `{{KEY}}` in a masked log is usually a resolved secret rather than a broken reference - but it is not proof. An unresolved name survives too: JavaScript and Python leave it literal, shell resolves it to the empty string, and a secret shorter than 8 characters is never masked at all, so its `{{KEY}}` is always unresolved. `sim --output json secrets list` proves only that a name exists, not that it resolved in this run. When a block behaves as though the credential were literal text, check the spelling there first - but never "fix" a working reference by rewriting it into `environmentVariables.KEY` or hardcoding a literal. Report which mode ran, the terminal status, and the relevant output or error. Include the run id when the selected execution mode returns one; `--follow` streams omit it. Never print profile credentials or raw secrets from block inputs.
GitHub에서 보기