// 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.
| name | ci-validation |
| description | 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. |
Use this skill for every workflow modification.
actionlint .github/workflows/*.ymlconftest test --rego-version v0 -o github --policy .github .github/workflows/*.yml./mvnw spotless:apply -T1C.claude/skills/act-testing/references/workflow-tiers.md and the rubric in .claude/skills/act-testing/SKILL.md..claude/skills/act-testing/SKILL.md before proceeding.test-*.yml harness, run check-drift.sh, assess act feasibility (act, docker, daemon), and provide user-run scenario commands.test-*.yml files only after user-run act validation is complete.act directly against production workflows.Do not skip step 1.
For every changed workflow, include:
workflow: <path>tier: <1|2|3>reason: <single sentence>evidence: <drift-check + feasibility + scenario matrix | tier-3 rationale>For Tier 1/2 workflows, evidence must explicitly contain:
test-workflow: <path>drift-check: <command + result>feasibility: act/docker/daemonscenario-matrix: <positive + negative at minimum>act-commands: <copy-paste ready plain text using canonical format: act <event> -e <event-json> -W <test-workflow> --secret-file .secrets --reuse; full workspace-relative paths; no markdown links in command text>cleanup: <test harness removed or justification>If these fields are missing, validation is incomplete and should not be reported as done.
actionlint + conftest + spotlessactionlint + conftest + spotless + actactionlint + conftest + spotless + rationaleCI: actionlint (workflows)CI: conftest (workflows policy)CI: verify skill markdown stabilityUse 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.
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?"