camunda

Use this skill to model and configure AI agents in Camunda 8 BPMN using the AI Agent Sub-process connector — an LLM driver applied to an ad-hoc subprocess with tools as BPMN activities. Use for: shaping the ad-hoc subprocess that hosts the agent, defining tools as service/script/user tasks or sub-processes, declaring LLM-supplied parameters via fromAi(), writing system/user prompt FEEL strings, wiring toolCallResult outputs, setting model and call limits, enabling multi-turn agent context, debugging tool-call resolution. Do not use for: the older AI Agent Task variant (see references/ai-agent-task.md), or generic BPMN authoring outside the agent host (use camunda-bpmn). **Workflow skill** — model the agent host, its tools, prompts, and limits. Covers c8ctl element-template apply for the AI Agent connector template.

Use this skill to author and run Camunda Process Test (CPT) suites that cover every BPMN gateway branch, DMN rule, and error boundary to 100%. Use for: scaffolding the `camunda-process-test-spring` harness, planning the minimum set of test segments for full element coverage, authoring `.test.json` instruction-based scenarios, running `mvn test`, parsing the CPT coverage report, deduplicating redundant segments. Do not use for: authoring the BPMN (use camunda-bpmn), writing FEEL or DMN expressions (use camunda-feel), deploying to a live cluster (use camunda-process-mgmt), UI or E2E tests against Operate or Tasklist. **Workflow skill** — segment-based authoring loop covering `mvn test`, coverage report parsing, and scenario deduplication.

Use this skill to build a custom Camunda 8 connector — outbound or inbound — when the OOTB catalog doesn't cover the integration. Two paths: a JSON-only element template on a protocol connector (no Java), or a Java connector via the Connectors SDK with annotation-driven template generation. Use for: choosing Path A (JSON-only protocol-connector template) vs Path B (custom Java); element template JSON; `OutboundConnectorProvider` + `@Operation` for outbound; `InboundConnectorExecutable` for webhook / subscription / polling inbound; SPI vs Spring-Bean registration; SaaS / SM / Hybrid hosting; element-template-generator Maven plugin. Do not use for: applying an OOTB connector (use camunda-connectors), worker-vs-connector decisions (use camunda-development), or job-worker handlers (use camunda-job-workers). **Workflow skill** — pick a path, write the template (and Java if Path B), register, host. Java 17+ on Path B.

Use this skill to install, configure, and operate c8ctl (the Camunda 8 CLI), the foundation the other camunda-* skills build on. Use for: starting a local cluster via c8run, connecting to Camunda 8 SaaS or Self-Managed via already-configured profiles, switching between connection profiles, managing connector secrets for the local cluster, switching c8ctl output modes for AI and scripting use, and any time another camunda-* skill calls c8ctl — load this first for the conventions (flags, profiles, output modes) shared across commands. Do not use for: writing BPMN (use camunda-bpmn), writing FEEL (use camunda-feel), or deploying and operating running processes (use camunda-process-mgmt — that skill builds on c8ctl). **Utility skill** — the foundation other camunda-* skills build on. Covers c8ctl cluster, c8ctl use profile, and the four default c8ctl plugins.

Use this skill to look up Camunda 8 documentation. The official docs at docs.camunda.io are the source of truth for current behavior — FEEL function signatures, BPMN extension attribute shapes, REST API endpoints, version requirements, feature availability. Trigger any time you need to verify a Camunda specific against the current docs, including when you think you already know the answer — Camunda 8 evolves fast and training data drifts. If you start with a conceptual explanation and find yourself about to state specifics (defaults, names, syntax, version requirements), stop and invoke before writing those specifics.

Use this skill to deploy BPMN, DMN, and form resources to a Camunda 8 cluster and operate live processes via c8ctl. Use for: deploying resources, starting process instances, inspecting running instances, listing or searching definitions and incidents, resolving incidents, completing user tasks, publishing correlation messages, cancelling instances, debugging stuck processes. Do not use for: authoring the BPMN, DMN, or form content itself (use camunda-bpmn, camunda-feel, camunda-forms), or installing and configuring c8ctl itself (use camunda-c8ctl). **Workflow skill** — operate a live cluster end-to-end. Covers c8ctl deploy, run, watch, list pi, search inc, complete ut, resolve inc, publish msg, cancel pi.

Use this skill to browse, configure, and apply pre-built Camunda connectors (REST, Slack, Kafka, AWS, etc.) via element templates (also known as connector templates). Use for: discovering available connector templates, inspecting their properties, applying a template to a service task or message event, configuring input mappings (URLs, request bodies, secrets) and result expressions, understanding the element template schema, debugging connector configuration in BPMN. Do not use for: writing free-form REST calls in service tasks (this skill is specifically for templated connectors), or modelling the BPMN structure itself (use camunda-bpmn). **Workflow skill** — discover, inspect, then apply. Covers c8ctl element-template search, info, get-properties, apply, get, sync.

Use this skill to create, edit, and validate BPMN 2.0 process diagrams for Camunda 8 (Zeebe). Use for: new BPMN processes, modifying existing diagrams, adding tasks/gateways/events/subprocesses, configuring Zeebe extensions (taskDefinition, ioMapping, loop characteristics), validating BPMN XML. Do not use for: writing FEEL expressions inside BPMN (use camunda-feel), designing form schemas (use camunda-forms), or deploying and running processes (use camunda-process-mgmt). **Workflow skill** — multi-step BPMN authoring. Covers c8ctl bpmn lint for validation.

Use when creating new pages, components, modules, or features in the orchestration cluster webapp at webapp/client/apps/orchestration-cluster-webapp/. Use when adding routes, data loading, forms, API integration, or UI components. Trigger whenever someone is building or modifying frontend feature code in webapp/client/, even for small changes like adding a column, filter, or panel.

Use when writing, modifying, or debugging unit tests in the orchestration cluster webapp at webapp/client/apps/orchestration-cluster-webapp/. Use when working with Vitest browser mode, MSW mocking, vitest-browser-react rendering, or any *.test.tsx file in the OC webapp's src/ directory. Trigger whenever someone needs to create, fix, or understand a frontend unit test in webapp/client/.

Prepares act-testable GitHub Actions workflow scenarios for this monorepo. Use when validating workflow logic locally, generating temporary test harnesses, checking logic drift, assessing local act feasibility, and proposing reproducible user-run test cases.

Validates GitHub Actions workflow changes in this monorepo using actionlint, conftest policy checks, spotless formatting, and act testability assessment. Use when creating, editing, or reviewing workflow files.

Detect CI runner underutilization and give downsizing recommendations for cost savings. Queries BigQuery CPU/memory metrics from self-hosted runners in camunda/camunda, identifies overprovisioned jobs, and suggests smaller runner types. Use when asked about CI costs, runner sizing, resource waste, underutilization, or right-sizing runners.

Use when writing, modifying, or debugging Playwright-based tests in the orchestration cluster webapp — integration tests, visual regression tests, or accessibility tests. Use when working with MSW network-level mocking via @msw/playwright, Page Object Models, axe-core accessibility checks, or screenshot comparisons. Trigger whenever someone is working in the test/ directory of the OC webapp at webapp/client/apps/orchestration-cluster-webapp/test/.

Use when migrating, porting, rewriting, or moving frontend code from operate/client/ or tasklist/client/ to the orchestration cluster webapp at webapp/client/apps/orchestration-cluster-webapp/. Trigger whenever someone mentions migrating a legacy page, component, or module to the new unified frontend, converting React Router to TanStack Router, replacing MobX stores with TanStack Query or URL state, rewriting styled-components as SCSS modules, or converting legacy test patterns to Vitest browser mode. Also use when someone asks how a legacy pattern maps to the new architecture, even for small questions like "how would I write this Operate component in the new app?" or "what's the equivalent of this Tasklist store in the unified frontend?"

Use when fixing bugs, making changes, writing tests, or understanding code in the Operate legacy frontend at operate/client/. Trigger for any work touching operate/client/src/, including component changes, test modifications, API hook updates, styled-components edits, MobX store changes, or React Router route adjustments. Also use when someone asks about Operate frontend patterns, conventions, or architecture. This is the legacy process monitoring UI being phased out in favor of the orchestration cluster webapp.

Use when the user wants to track a phase of work within a feature, says "create an epic for phase X", "track this phase", or needs to group related tasks under a milestone. Epics sit between features and tasks in the hierarchy.

Use when the user asks to write an ADR, says "create an ADR for X", "document this decision", "we need an ADR", or whenever you're about to make a significant design choice — introducing a port/adapter/SPI, picking between viable approaches, altering data flow, adding a dependency, or establishing a project-wide convention. Default to invoking this skill for any architectural change.

Use when the user wants an orientation to this repo, says "tour", "show me around", "what can I do here", "how does this repo work", "I'm new here", or wants to know the available slash commands and project structure

Use when the user asks to track a task, says "create a task for X", "break this feature into tasks", "we need to implement X", or wants a small, self-contained unit of work captured as an issue (standalone or as part of a feature)

Use when the user reports a bug, says "track this bug", "this is broken", "the behavior should be X", or describes unexpected behavior they want fixed

Use when the user asks to document something in the codebase, says "document this", "add docs for", "write documentation for", or wants code-level documentation created or updated

Use when the user requests a new capability, says "we should be able to", "add support for", "I want to be able to", or describes functionality that doesn't exist yet

Review an engineering spec, design doc, or WIP RFC through a product-sense lens — problem framing, user fit, product fit, and whether the spec is framed clearly enough for the team to act on it. Calibrates to the spec's maturity stage (early direction, partial spec, ready-for-define) so early-stage work gets direction feedback, not premature spec polish. Use before implementation begins, on work-in-progress specs. Output is a structured review posted inline in the conversation — does NOT write files to the working directory. Triggers on: "review this spec", "review this RFC", "review this design", "PM review", "spec review", "product-sense review", a GitHub issue/PR link containing a spec body, a Google Doc design doc link, or a pasted spec. Use when user: asks for a structured review of an engineering proposal before Define/build; needs to surface cross-product dependencies or hidden deferrals; wants to validate problem framing, scope, and edge states before committing to implementation; or wants a second o

Create an Architecture Decision Record (ADR) as a Markdown file. Triggers on: "write an ADR", "capture this decision", "migrate this doc into an ADR", architecture folder, decision records, ADR numbering/renumbering, and requests to turn a Google Doc / kickoff note / conversation outcome into a durable decision record. Use when user: asks to create or migrate an ADR, records a just-made architectural decision, adds a decision to an existing ADR folder (e.g. docs/adrs/), or needs to align a draft with the house ADR format.

Writes documentation for the current code changes and raises a PR to camunda/camunda-docs — or updates an existing docs PR if one is already open for this branch.

Searches Camunda 8 documentation for domain knowledge needed during implementation. Use when a change involves Camunda-specific concepts, APIs, configuration, or behavior — such as BPMN, DMN, Zeebe, Connectors, Operate, Tasklist, Identity, or any Camunda platform component.

Validates structural or foundational code changes against Camunda architecture principles. Use when a change alters module boundaries, APIs, data flows, core architecture, domain models, or protocols.

Use this when migrating or converting a Camunda 7 / camunda-bpm Java/Spring codebase to Camunda 8 — including JavaDelegates, ExternalTaskWorkers, ProcessEngine/RuntimeService client code, and application.properties/application.yaml with camunda.* keys.

Iterate on a feature by fetching GitHub Actions CI logs, statuses, and artifacts to debug failures locally. USE WHEN: a PR has failing CI checks, the user asks to "debug CI", "fix the pipeline", "why is the test failing in CI", "fetch the CI logs", "check the CI", or wants to set up a fix-push-recheck loop. INVOKES: gh CLI (run list/view/download), local zip/json parsing. DO NOT USE FOR: triggering new runs, modifying workflows themselves, or general code review.