Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Start an Output SDK workflow asynchronously without waiting for completion. Use when starting long-running workflows, getting a workflow ID for later monitoring, running workflows in the background, or executing multiple workflows in parallel.
.claude/skills/growthxai-output-workflow-start/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-08 | ✗→✓ | ▲ Improved | 29% | 0% |
| case-01 | ✗→✓ | ▲ Improved | -38% | 0% |
| case-02 | ✗→✓ | ▲ Improved | 32% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 21% | 0% |
| case-04 | ✗→✓ | ▲ Improved | 37% | 0% |
This skill starts a workflow asynchronously, meaning the command returns immediately with a workflow ID while the workflow executes in the background. Use this for long-running workflows or when you need to run multiple workflows in parallel.
Consider using npx output workflow run (sync) when:
bashnpx output workflow start <workflowName> --input '<json-input>' npx output workflow start <workflowName> --input <path-to-json-file>
The --input flag is required when the workflow expects input data.
Pass JSON directly on the command line:
bashnpx output workflow start data-migration --input '{"batchSize": 1000}'
Reference a JSON file containing the input:
bashnpx output workflow start data-migration --input src/data_migration/scenarios/large_batch.json
This is the recommended approach because:
The command outputs the workflow ID which you'll need for:
npx output workflow status <id>npx output workflow result <id>npx output workflow debug <id>Add --monitor (-m) to attach immediately after starting and stream step updates until the workflow ends, instead of polling workflow status:
bashnpx output workflow start data-migration --input src/data_migration/scenarios/large_batch.json --monitor
This attaches to the exact run that was just started. Ctrl+C detaches without stopping the workflow (exit 130), and the command exits 1 if the workflow fails. If monitoring itself drops (an API restart, a reset connection), the workflow keeps running and the command exits 3 instead — so a retry keyed on a failed workflow can't re-submit one that is already in flight.
Monitoring reports progress, not the return value; the command closes by naming the follow-up — npx output workflow result <id> after a run that completed, npx output workflow debug <id> after one that failed.
These flags tune the stream and require --monitor:
| Flag | Default | Description | |------|---------|-------------| | --interval | 2500 | Poll interval in milliseconds | | --include-payloads | false | Include decoded step input/output payloads | | --color | true | Colorize status output (--no-color to disable) |
--monitor cannot be combined with --json. Under --json the CLI suppresses progress output and prints one JSON object at the end, so the stream would be silently swallowed and the command would look hung until the workflow finished. To get JSON, either use npx output workflow run --json (wait for the result), or start without --monitor and attach with npx output workflow monitor <id> --format json (streaming NDJSON).
Prefer --monitor over a workflow status polling loop when you're watching a single workflow through to completion. Keep the plain async form when starting several workflows in parallel, since --monitor blocks until the run ends.
Scenario: Start a long-running workflow with scenario file
bashnpx output workflow start data-migration --input src/data_migration/scenarios/full_migration.json # Output: # Started workflow: data-migration # Workflow ID: abc123xyz # Use 'npx output workflow status abc123xyz' to check progress
Scenario: Start multiple workflows in parallel using scenario files
bash# Start several workflows with different scenario files npx output workflow start process-batch --input src/process_batch/scenarios/batch_1.json npx output workflow start process-batch --input src/process_batch/scenarios/batch_2.json npx output workflow start process-batch --input src/process_batch/scenarios/batch_3.json # Note: Save the workflow IDs to check them later
Scenario: Create scenario then start workflow
bash# Create a scenario file mkdir -p src/generate_report/scenarios cat > src/generate_report/scenarios/annual_2024.json << 'EOF' { "year": 2024, "includeCharts": true, "format": "pdf" } EOF # Start the workflow npx output workflow start generate-report --input src/generate_report/scenarios/annual_2024.json # Output: Workflow ID: report-2024-abc # Check status periodically npx output workflow status report-2024-abc # Output: Status: RUNNING # Later, check again npx output workflow status report-2024-abc # Output: Status: COMPLETED # Get the result npx output workflow result report-2024-abc
Scenario: Quick inline test for development
bashnpx output workflow start quick-job --input '{"test": true}'
Scenario: Script for parallel execution
bash# Start workflows and capture IDs ID1=$(npx output workflow start job --input src/job/scenarios/type_a.json | grep "Workflow ID" | cut -d: -f2 | tr -d ' ') ID2=$(npx output workflow start job --input src/job/scenarios/type_b.json | grep "Workflow ID" | cut -d: -f2 | tr -d ' ') # Wait and check results npx output workflow result $ID1 npx output workflow result $ID2
bashnpx output workflow status <workflowId>
Status values:
bashnpx output workflow result <workflowId>
Only works for COMPLETED workflows. For FAILED workflows, use debug.
bashnpx output workflow debug <workflowId> --json
bashnpx output workflow stop <workflowId>
When starting multiple workflows, keep track of IDs:
bash# Log IDs to a file npx output workflow start batch-job --input src/batch_job/scenarios/id_1.json >> workflow-ids.txt npx output workflow start batch-job --input src/batch_job/scenarios/id_2.json >> workflow-ids.txt # Or use a naming convention in your workflow that makes IDs predictable
src/<workflow>/scenarios/ for reproducibilitynpx output workflow status to check progressnpx output workflow stopnpx output workflow run <name> --input - Execute synchronouslynpx output workflow monitor <id> - Attach to a run already in progressnpx output workflow status <id> - Check execution statusnpx output workflow result <id> - Get execution resultnpx output workflow stop <id> - Stop a running workflownpx output workflow debug <id> - Debug a workflow execution| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-08 | fail→pass | 15,036 | 5,920 | -61% | 1 | 1 | 0% | 2,174 | 2,813 | +29% | 0 | 0 | — |
case-01 | fail→pass | 49,081 | 3,344 | -93% | 1 | 1 | 0% | 3,963 | 2,467 | -38% | 0 | 0 | — |
case-02 | fail→pass | 11,544 | 3,502 | -70% | 1 | 1 | 0% | 1,884 | 2,478 | +32% | 0 | 0 | — |
case-03 | fail→pass | 11,699 | 3,174 | -73% | 1 | 1 | 0% | 1,960 | 2,372 | +21% | 0 | 0 | — |
case-04 | fail→pass | 10,281 | 2,095 | -80% | 1 | 1 | 0% | 1,590 | 2,176 | +37% | 0 | 0 | — |
case-05 | fail→pass | 4,422 | 3,131 | -29% | 1 | 1 | 0% | 728 | 2,350 | +223% | 0 | 0 | — |
case-06 | fail→pass | 6,849 | 1,339 | -80% | 1 | 1 | 0% | 1,096 | 2,051 | +87% | 0 | 0 | — |
case-07 | fail→pass | 22,456 | 2,856 | -87% | 1 | 1 | 0% | 3,696 | 2,320 | -37% | 0 | 0 | — |
case-09 | pass→pass | 9,283 | 2,890 | -69% | 1 | 1 | 0% | 1,498 | 2,334 | +56% | 0 | 0 | — |
case-10 | fail→pass | 10,590 | 1,900 | -82% | 1 | 1 | 0% | 1,579 | 2,170 | +37% | 0 | 0 | — |
case-11 | fail→pass | 13,608 | 1,580 | -88% | 1 | 1 | 0% | 2,028 | 2,085 | +3% | 0 | 0 | — |
case-12 | fail→pass | 14,578 | 1,890 | -87% | 1 | 1 | 0% | 2,411 | 2,141 | -11% | 0 | 0 | — |
case-13 | fail→pass | 9,155 | 1,682 | -82% | 1 | 1 | 0% | 1,617 | 2,113 | +31% | 0 | 0 | — |
case-14 | fail→pass | 12,486 | 6,081 | -51% | 1 | 1 | 0% | 2,214 | 3,079 | +39% | 0 | 0 | — |
case-15 | fail→pass | 10,703 | 3,245 | -70% | 1 | 1 | 0% | 1,739 | 2,395 | +38% | 0 | 0 | — |
case-16 | pass→pass | 9,476 | 6,059 | -36% | 1 | 1 | 0% | 1,439 | 2,790 | +94% | 0 | 0 | — |
case-22 | fail→pass | 24,363 | 2,097 | -91% | 1 | 1 | 0% | 4,203 | 2,168 | -48% | 0 | 0 | — |
case-17 | pass→pass | 15,185 | 5,225 | -66% | 1 | 1 | 0% | 2,152 | 2,649 | +23% | 0 | 0 | — |
case-18 | fail→pass | 14,051 | 2,405 | -83% | 1 | 1 | 0% | 2,216 | 2,209 | -0% | 0 | 0 | — |
case-19 | fail→pass | 9,642 | 3,455 | -64% | 1 | 1 | 0% | 1,612 | 2,367 | +47% | 0 | 0 | — |
case-20 | fail→pass | 9,565 | 2,132 | -78% | 1 | 1 | 0% | 1,613 | 2,168 | +34% | 0 | 0 | — |
case-21 | fail→pass | 8,631 | 1,679 | -81% | 1 | 1 | 0% | 1,345 | 2,159 | +61% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 22 cases were attempted. The headline lift of +86 percentage points is the difference between those two pass rates over the 22 comparable cases.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.