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.

Informations de source

Dépôt
simstudioai/skills
Dernière activité de la source
29 septembre 2026 à 20:18
Langue détectée de SKILL.md
anglais
Étoiles
1
Forks
1

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

Affichage de SKILL.md

SKILL.md
Instructions source · Aperçu en lecture seule
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.
Voir sur GitHub