How do I install the Invoke Workflow skill?

Run npx skillmds@latest add getlark/invoke-workflow in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Invoke Workflow safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Invoke Workflow?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Invoke Workflow free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under MIT.

Who published Invoke Workflow?

getlark (@getlark) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Invoke Workflow by getlark — Agent Skill

Name: Invoke Workflow
Author: getlark

Invoke Workflow

This skill should be used when the user asks to "run a workflow", "invoke a larkci workflow", "run getlark tests", "trigger a test", "run all workflows", or runs `/getlark:invoke-workflow`. Invokes one or more getlark workflows, waits for terminal status, and reports pass/fail summaries. Prefer `validate-branch` when the user wants to gate a git branch (it picks the right workflows automatically); use `manage` to inspect past executions without kicking off a new run; use `create-workflow` first if no workflow exists yet.

getlark 2a71274 3.7 KB Updated Sep 17, 2026

File contents

invoke-workflow

Run one or more getlark workflows and wait for completion, then report results. Default behavior is invoke + poll — the user gets a verdict, not just an execution ID.

Inputs

Accept any of:

A specific workflow ID (wf_...)
A workflow name (resolve to ID via getlark workflows list)
A workflow group ID or group name
--all / "all" to run everything

If the user ran /getlark:invoke-workflow <arg>, parse <arg> accordingly. Otherwise ask.

Procedure

Step 1 — Resolve target(s)

Based on input shape:

Input	Resolution
Starts with `wf_`	Use directly as `--workflow-ids`
Looks like a name	`getlark workflows list --limit 100`, find match by `name`, use its `id`. If multiple match, ask.
Group ID (`wfl_grp_*` or similar)	Use `--group-id`
Group name	Use `--group-name "<name>"`
`all` / `--all` / unspecified + user said "everything"	Use `--all`

Step 2 — Invoke with wait

Always pass --wait by default. Set a timeout that matches the expected run time; --timeout 600 (10 min) is a reasonable default for a single workflow, scale up for --all or large groups.

getlark workflows invoke \
  --workflow-ids <id> \
  --wait \
  --timeout 600

Or for multiple:

getlark workflows invoke --all --wait --timeout 1800

If the user explicitly says "don't wait" / "fire and forget", drop --wait.

Step 3 — Interpret exit code & output

Exit	Meaning	Action
0	All invoked workflows succeeded	Report ✅ with execution IDs
1	One or more workflows failed	List failing workflow IDs + their summaries
2	Timed out	Tell the user, offer to extend `--timeout` or check via `/getlark:manage`
3	Unexpected error	Surface stderr verbatim

The CLI prints one line per workflow:

Success: Workflow <id> executed successfully. Execution ID: <exec_id>
Failure: Workflow <id> executed with failure. Execution ID: <exec_id>. Summary: <summary>
Cancelled: Workflow <id> was cancelled. Execution ID: <exec_id>

Parse these lines into a concise report for the user.

Step 4 — On failure: offer debug actions (do not auto-run)

If any workflow failed, offer — do not auto-execute — follow-ups:

"Run getlark workflows executions get <wf_id> <exec_id> to see step-by-step details?"
"Fetch logs with getlark workflows executions logs <wf_id> <exec_id>?"
"Trigger a repair with getlark workflows repairs trigger <wf_id>?"

Wait for user confirmation before running any of these.

Dashboard links

For any execution, surface: https://dashboard.getlark.ai/workflows/<wf_id>/executions/<exec_id>

Examples

Single workflow by ID:

getlark workflows invoke --workflow-ids wf_abc123 --wait

Group by name:

getlark workflows invoke --group-name "Checkout Flow" --wait --timeout 1800

Everything:

getlark workflows invoke --all --wait --timeout 3600

Do NOT

Do not silently swallow a non-zero exit code.
Do not invent execution or workflow IDs — derive them only from CLI output or prior list/get calls.
Do not automatically fetch repairs/logs/generations on failure — offer first.

---name: invoke-workflowdescription: This skill should be used when the user asks to "run a workflow", "invoke a larkci workflow", "run getlark tests", "trigger a test", "run all workflows", or runs `/getlark:invoke-workflow`. Invokes one or more getlark workflows, waits for terminal status, and reports pass/fail summaries. Prefer `validate-branch` when the user wants to gate a git branch (it picks the right workflows automatically); use `manage` to inspect past executions without kicking off a new run; use `create-workflow` first if no workflow exists yet.license: MIT---# invoke-workflowRun one or more getlark workflows and wait for completion, then report results. Default behavior is **invoke + poll** — the user gets a verdict, not just an execution ID.## InputsAccept any of:- A specific workflow ID (`wf_...`)- A workflow name (resolve to ID via `getlark workflows list`)- A workflow group ID or group name- `--all` / "all" to run everythingIf the user ran `/getlark:invoke-workflow <arg>`, parse `<arg>` accordingly. Otherwise ask.## Procedure### Step 1 — Resolve target(s)Based on input shape:| Input | Resolution ||---|---|| Starts with `wf_` | Use directly as `--workflow-ids` || Looks like a name | `getlark workflows list --limit 100`, find match by `name`, use its `id`. If multiple match, ask. || Group ID (`wfl_grp_*` or similar) | Use `--group-id` || Group name | Use `--group-name "<name>"` || `all` / `--all` / unspecified + user said "everything" | Use `--all` |### Step 2 — Invoke with waitAlways pass `--wait` by default. Set a timeout that matches the expected run time; `--timeout 600` (10 min) is a reasonable default for a single workflow, scale up for `--all` or large groups.```bashgetlark workflows invoke \ --workflow-ids <id> \ --wait \ --timeout 600```Or for multiple:```bashgetlark workflows invoke --all --wait --timeout 1800```If the user explicitly says "don't wait" / "fire and forget", drop `--wait`.### Step 3 — Interpret exit code & output| Exit | Meaning | Action ||---|---|---|| 0 | All invoked workflows succeeded | Report ✅ with execution IDs || 1 | One or more workflows failed | List failing workflow IDs + their summaries || 2 | Timed out | Tell the user, offer to extend `--timeout` or check via `/getlark:manage` || 3 | Unexpected error | Surface stderr verbatim |The CLI prints one line per workflow:- Success: `Workflow <id> executed successfully. Execution ID: <exec_id>`- Failure: `Workflow <id> executed with failure. Execution ID: <exec_id>. Summary: <summary>`- Cancelled: `Workflow <id> was cancelled. Execution ID: <exec_id>`Parse these lines into a concise report for the user.### Step 4 — On failure: offer debug actions (do not auto-run)If any workflow failed, offer — do not auto-execute — follow-ups:- "Run `getlark workflows executions get <wf_id> <exec_id>` to see step-by-step details?"- "Fetch logs with `getlark workflows executions logs <wf_id> <exec_id>`?"- "Trigger a repair with `getlark workflows repairs trigger <wf_id>`?"Wait for user confirmation before running any of these.## Dashboard linksFor any execution, surface: `https://dashboard.getlark.ai/workflows/<wf_id>/executions/<exec_id>`## Examples**Single workflow by ID:**```bashgetlark workflows invoke --workflow-ids wf_abc123 --wait```**Group by name:**```bashgetlark workflows invoke --group-name "Checkout Flow" --wait --timeout 1800```**Everything:**```bashgetlark workflows invoke --all --wait --timeout 3600```## Do NOT- Do not silently swallow a non-zero exit code.- Do not invent execution or workflow IDs — derive them only from CLI output or prior `list`/`get` calls.- Do not automatically fetch repairs/logs/generations on failure — offer first.

Frequently asked questions