Install
$ agentstack add skill-camunda-skills-camunda-process-mgmt ✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
Verified badge
Passed review? Show it. Paste this badge into your README, it links to the public security report.
Reliability & compatibility
Declared compatibility
Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.
We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.
How agent discovery & health will work →About
Camunda Process Management
Runtime operations for Camunda 8.8+ clusters via c8ctl: deploy resources, start instances, inspect state, resolve incidents, complete tasks, publish messages, cancel instances. Single skill for everything that happens after the model is written.
Prerequisites
- Camunda 8.8+ cluster (local via c8run, SaaS, or Self-Managed)
- c8ctl CLI installed and a profile configured for the target cluster — see camunda-c8ctl for setup
Cross-References
- camunda-c8ctl: Use for c8ctl setup, cluster safety, and shared conventions (flags, profiles, output modes)
- camunda-bpmn: Use for fixing BPMN process issues found during debugging
- camunda-dmn: Use for fixing DMN decision issues —
EXTRACT_VALUE_ERROR/DECISION_EVALUATION_FAILEDincidents typically trace back to the decision file - camunda-connectors: Use for fixing connector configuration issues found during debugging
- camunda-job-workers: Use when an incident traces back to handler code rather than the process model — the worker side of
zeebe:taskDefinition type - camunda-connectors-development: Use when an incident traces back to a custom connector's runtime / registration / hosting rather than its template configuration
- camunda-feel: Use for diagnosing FEEL evaluation errors (EXTRACTVALUEERROR, CONDITION_ERROR) in incidents
- camunda-process-test: Use for testing processes against an embedded Zeebe engine
Instructions
Deploying Resources
Cluster safety — ask before deploying to anything that isn't local c8run.
The globally-active c8ctl profile might still point at a shared cluster (prod, staging, customer name, …) from a previous session. A bare c8ctl deploy process.bpmn then silently writes there.
- Run
c8ctl which profilefirst. If the name suggests a shared environment, confirm with the user before deploying. - Always pass
--profile=explicitly ondeployand other mutating commands (run,cancel,resolve,complete,publish,watch). - For validation deploys (just running the change once to check it works), prefer
--profile=localagainst a running c8run cluster —c8ctl cluster startif not running.
See camunda-c8ctl for the authoritative cluster-safety rules.
Example — deploy a single BPMN file to the local profile:
c8ctl deploy process.bpmn --profile=local
Deploy multiple resources at once (BPMN, DMN, forms):
c8ctl deploy process.bpmn decision.dmn approval-form.form
Deploy an entire directory (recursive):
c8ctl deploy ./my-project
After deploying, verify:
c8ctl list pd
c8ctl search pd --iname="MyProcess"
Each deployment creates a new version of any resource it contains. Use c8ctl list pd --fields Key,Name,Version to see versions.
Starting Process Instances
Create an instance for a deployed process:
c8ctl create pi --id MyProcess
With input variables:
c8ctl create pi --id MyProcess --variables '{"orderId": "ORD-123", "amount": 1500}'
Deploy and start in one step:
c8ctl run process.bpmn --variables '{"orderId": "ORD-123"}'
Start and block until the instance completes (useful for tests / smoke checks):
c8ctl await pi --id MyProcess --variables '{"orderId": "ORD-123"}'
With a custom request timeout:
c8ctl await pi --id MyProcess --requestTimeout 60000
Not for long-running activities. await pi uses the cluster's start-and-wait REST endpoint, which times out before any single activity that runs longer than the request timeout (LLM agents, slow HTTP calls, user tasks). The timed-out response carries no instance key, so you can't follow up on the partial run. For those processes, use c8ctl create pi and poll c8ctl get pi until terminal state, or fall back to c8ctl search pi --state=ACTIVE to recover the orphaned instance after a failed await.
Watch Mode (Development)
Auto-redeploy on file changes during local development:
c8ctl watch ./my-project
Watches .bpmn, .dmn, and .form files and redeploys on save.
Inspecting Process Instances
List active instances:
c8ctl list pi
Search by process name (i prefix means case-insensitive substring match):
c8ctl search pi --iprocessDefinitionName="MyProcess"
Get instance details with variables:
c8ctl get pi --variables
Dump variable values for a specific instance (use --fullValue to avoid truncation):
c8ctl search variables --processInstanceKey= --fullValue
Retrieve the deployed BPMN XML for a process definition:
c8ctl get pd --xml
Resolving Incidents
Incidents are the cluster's way of pausing an instance when something fails non-recoverably (FEEL error, missing variable, connector failure, job timeout exceeded retries). Always inspect before resolving.
First-response triage — when a user reports "instance X is stuck", run these four in sequence to assess before deciding to resolve:
PI=
c8ctl get pi $PI # state (ACTIVE = stuck on a step), processDefinitionId
c8ctl search inc --processInstanceKey=$PI # any incidents on this PI, with errorType
c8ctl search variables --processInstanceKey=$PI --fullValue # variables at the failure point
c8ctl get inc --json # full error message
The four together usually localise the cause without needing to open Operate.
List active incidents:
c8ctl list inc
c8ctl search inc --state=ACTIVE
Filter by error message:
c8ctl search inc --ierrorMessage="Connection refused"
Debug workflow when a process has an incident:
- Find the incident and read the error type + message:
``bash c8ctl search inc --state=ACTIVE ``
- Inspect the instance variables at the failure point:
``bash c8ctl search variables --processInstanceKey= --fullValue ``
- Identify root cause. Common categories:
- FEEL error (EXTRACTVALUEERROR / CONDITION_ERROR) → cross-ref camunda-feel for expression fixes; check for dotted-variable shadowing or null inputs
- Job worker missing or timing out → check the `` matches a running worker
- Connector misconfiguration → cross-ref camunda-connectors to fix the element template binding
- BPMN logic bug → cross-ref camunda-bpmn to fix and redeploy
- Fix the underlying issue (BPMN edit, connector reconfig, worker fix, or variable correction).
- Resolve the incident to retry the failed step:
``bash c8ctl resolve inc ``
Resolving without fixing the root cause just re-triggers the same incident. Always fix first.
Completing User Tasks
List pending user tasks:
c8ctl list ut
Complete with output variables:
c8ctl complete ut --variables '{"approved": true, "comments": "Looks good"}'
Variable keys must match the form's component key values (see camunda-forms) — extra keys are ignored; missing required keys block completion downstream.
Publishing Correlation Messages
Publish a message to wake up a waiting message event in an instance:
c8ctl publish msg --correlationKey= --variables '{"status": "approved"}'
The correlation key must match the value resolved from the process's message subscription expression (typically a FEEL expression over a variable, e.g. =orderId).
Cancelling Instances
c8ctl cancel pi
JSON Output for Scripting
Pass --json per call, optionally narrowed with --fields. Don't toggle session-wide output mode — see camunda-c8ctl for the why.
c8ctl list pi --json --fields=key,state,bpmnProcessId
c8ctl list pd --json --fields=key,bpmnProcessId,version
c8ctl get inc --json
Troubleshooting
Deployment fails — Run c8ctl bpmn lint process.bpmn first (see camunda-bpmn). Most deploy errors are caught by the linter pre-deploy.
Process won't start — Verify the process ID matches a deployed definition (c8ctl list pd). Check required input variables.
Instance hangs at a service task — No worker is registered for that task type, the worker crashed, or the job timed out beyond max retries. Check c8ctl list jobs --processInstanceKey= and confirm a worker process is running for the matching task type.
Repeated identical incidents — You're resolving without fixing. Read the error message every time; if it doesn't change, the root cause hasn't been addressed.
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: camunda
- Source: camunda/skills
- License: Apache-2.0
- Homepage: https://camunda.com
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet, be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.