From camunda-skills
Deploys BPMN, DMN, and form resources to a Camunda 8 cluster and operates live processes via c8ctl. Use for deploying, starting instances, inspecting state, resolving incidents, completing tasks, publishing messages, and canceling instances.
How this skill is triggered — by the user, by Claude, or both
Slash command
/camunda-skills:camunda-process-mgmtThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
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.
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.
EXTRACT_VALUE_ERROR / DECISION_EVALUATION_FAILED incidents typically trace back to the decision filezeebe:taskDefinition typeCluster 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.
c8ctl which profile first. If the name suggests a shared environment, confirm with the user before deploying.--profile=<name> explicitly on deploy and other mutating commands (run, cancel, resolve, complete, publish, watch).--profile=local against a running c8run cluster — c8ctl cluster start if 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.
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 <key> until terminal state, or fall back to c8ctl search pi --state=ACTIVE to recover the orphaned instance after a failed await.
Auto-redeploy on file changes during local development:
c8ctl watch ./my-project
Watches .bpmn, .dmn, and .form files and redeploys on save.
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 <instanceKey> --variables
Dump variable values for a specific instance (use --fullValue to avoid truncation):
c8ctl search variables --processInstanceKey=<key> --fullValue
Retrieve the deployed BPMN XML for a process definition:
c8ctl get pd <key> --xml
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=<instanceKey>
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 <incidentKey> --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:
c8ctl search inc --state=ACTIVE
Inspect the instance variables at the failure point:
c8ctl search variables --processInstanceKey=<key> --fullValue
Identify root cause. Common categories:
<zeebe:taskDefinition type="..."> matches a running workerFix the underlying issue (BPMN edit, connector reconfig, worker fix, or variable correction).
Resolve the incident to retry the failed step:
c8ctl resolve inc <incidentKey>
Resolving without fixing the root cause just re-triggers the same incident. Always fix first.
List pending user tasks:
c8ctl list ut
Complete with output variables:
c8ctl complete ut <taskKey> --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.
Publish a message to wake up a waiting message event in an instance:
c8ctl publish msg <messageName> --correlationKey=<key> --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).
c8ctl cancel pi <instanceKey>
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 <key> --json
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=<key> 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.
npx claudepluginhub camunda/skills --plugin camunda-skillsGuides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.