run-existing-slx

Run an Existing SLX

Execute a committed SLX runbook on the workspace runner.

When to use

• User asks to "run", "execute", or "trigger" a health check or task
• User references a specific SLX by name (e.g. "run k8s-pod-health")
• User wants to re-run a check to verify a fix
• User asks workspace_chat to run something (workspace_chat CANNOT execute tasks)

Critical: workspace_chat limitations

workspace_chat can search, analyze, and describe tasks — but it CANNOT execute them.

When a user says "run task X" through workspace_chat, it will describe the task but not actually trigger it. You MUST use run_slx for execution.

Action	Correct tool
Find available tasks	search_workspace or workspace_chat
See what a task does	get_slx_runbook or workspace_chat
View recent run results	get_run_sessions or workspace_chat
Actually execute a task	run_slx
Run an ad-hoc script (not committed)	run_script_and_wait

Workflow

1. Find the SLX — Use search_workspace or get_workspace_slxs to find the SLX name
2. Verify it (optional) — Use get_slx_runbook to see what tasks it will run
3. Execute — Call run_slx with the SLX short name
4. Review results — The tool returns pass/fail status and output

Critical: always use task_titles="*"

SLX runbooks register task names as the literal Robot variable ${TASK_TITLE} (resolved at runtime), not the human-readable title shown in get_slx_runbook. Passing a display title (e.g. "GitHub Project Board Daily Update") produces empty passed_titles — the run looks empty even though the SLX exists. The MCP rejects such literals with Unsupported task_titles value.

• Default: omit task_titles or pass task_titles="*" (runs all tasks)
• Advanced: pass task_titles="${TASK_TITLE}" only when you know the exact Robot variable name stored in the runbook
• Never: copy the resolved title from get_slx_runbook into task_titles