camunda

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.

Route gh-aw workflow create/debug/upgrade requests to the right prompts.

Use when adding support for a new event or metric in the analytics exporter at zeebe/exporters/analytics-exporter/ — creating handlers, adding AnalyticsAttributes, registering in the HandlerRegistry, and writing tests. Also use when modifying existing handlers or attributes.

Shepherd one or more camunda/camunda PRs through flaky CI and the merge queue to merged. Accepts a list of PRs (e.g. a merge plus its backports). Use when asked to babysit, shepherd, watch, drive, or "get merged" one or more PRs, or to keep retrying CI until they land.

Autonomously investigate a GitHub issue in camunda/camunda — read it, find the relevant code, reproduce it, root-cause it, and validate a fix, posting progress as a single updating issue comment. At Medium/High confidence, implements the fix and opens it as a draft PR. Use when asked to investigate, triage-deep-dive, or look into a specific bug issue (given a URL or issue number).

Use when you add, change, or remove schemas, fields, enums, filters, sort fields, or endpoints in @camunda/camunda-api-zod-schemas (webapp/client/packages/camunda-api-zod-schemas/); when you align the package with the OpenAPI spec in zeebe/gateway-protocol/src/main/proto/v2/; when you add a module or a release-line version tree; or when you increase the package version and prepare a release.

Diagnose failing GitHub Actions runs and propose fixes. Use when given a GHA run/job URL, or asked why CI failed, why a job failed, what broke in a run, or to fix a red check on a PR.

Triages a flood of CI incidents in camunda/camunda. Use when multiple CI incidents open in a short window and the medic needs to orient fast — find the shared pattern, identify outliers, and know what to do next. Re-runnable as new incidents arrive.

Drive CI incident response in camunda/camunda. Use when asked to resolve, respond to, or drive a CI incident by ID. Full incidents only, not alerts.

Analyze CI failure patterns for push-triggered workflow jobs on main and stable/* branches. Use when asked about CI health, broken jobs, flaky workflows, failure rates, or push-trigger problems.

Detect CI runner underutilization and recommend downsizing for cost savings. Use when asked about CI costs, runner sizing, resource waste, underutilization, or right-sizing self-hosted runners.

Generate a health report for scheduled GitHub Actions workflows in this monorepo. Use when asked about scheduled workflow health, nightly build failures, flaky CI, or workflow ownership.

Enforces GitHub Actions security and compliance for this monorepo. Use when adding third-party actions, handling secrets, defining permissions, and reviewing CI security trade-offs.

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.

Authors and refactors GitHub Actions workflows and composite actions for this monorepo using required conventions, minimal permissions, pinned SHAs, and observability steps. Use when creating or restructuring CI workflows.

Create a GitHub issue in camunda/camunda with the correct template, component label, and parent link. Use when asked to create, file, or open an issue — for bugs, features, tasks, tech debt, or CVEs.

Create a GitHub issue in camunda/camunda for load-test/Reliability Testing (RT) work, extending create-issue with the component/load-tests label and an rt/foundation, rt/coverage, or rt/enablement classification. Use when asked to create, file, or open an RT/load-test issue.

Use when migrating orchestration cluster webapp pages or components from Carbon to the Camunda design system (shadcn), including parallel routes, side-by-side components, and migration tests.

Use when implementing, fixing, or reviewing Zeebe engine code in zeebe/engine/ — BPMN process execution, DMN decision evaluation, job lifecycle, user/identity management, batch operations, variables, deployments, signals, messages, timers, multi-tenancy, or authorization. Also when modifying or reviewing processors, event appliers, state classes, record value types, intents, or engine tests.

Use when building or modifying pages, components, modules, routes, data loading, forms, API integration, or UI features — including small changes like a column, filter, or panel — in the orchestration cluster webapp (webapp/client/apps/orchestration-cluster-webapp/).