CI and Release Engineering

Use this skill for provider workflow and release automation configuration. Keep the change scoped to the checked-in pipeline contract; inspect local conventions and provider documentation before assuming syntax or behavior.

Workflow

1. Inspect the changed workflow files, repository instructions, existing release process, referenced scripts, package metadata, and recent pipeline behavior. Identify the provider, event source, protected refs, intended release unit, and the commands the workflow invokes.
2. Define the execution contract before editing: triggers, path filters, event payload assumptions, ref and tag selection, job dependencies, matrix axes, service lifecycle, cache keys, artifact producers and consumers, and failure propagation.
3. Apply the smallest workflow change. Make job ordering and needs explicit; keep matrix expansion bounded; scope cache keys and artifact names to the inputs that affect them; prevent cancellation or concurrency rules from interrupting work that must finish.
4. For releases, make version source, tag/ref selection, publication target, immutability, rerun behavior, and recovery path explicit. A retry must not duplicate a release, overwrite an unintended artifact, or publish from a different commit.
5. Define environment and promotion gates deliberately. Separate build, verification, approval, and publication where the provider supports it; do not encode production deployment infrastructure in this skill's scope.
6. Verify with the provider's available workflow linting, schema checks, static contract tests, and safe local emulation. Treat local emulation as incomplete evidence for provider events, permissions, hosted runners, protected refs, environments, caches, and release APIs.
7. Run the narrowest repository-owned commands affected by the pipeline, then inspect the rendered workflow or a safe test run when available. Record what could only be verified remotely.

Security and Supply Chain Guardrails

• Never print or persist secrets, tokens, credentials, private artifact URLs, or unredacted workflow logs.
• Load security-review and security-review-evidence for permissions, secrets, OIDC, untrusted events or forks, command injection, artifact trust, or privileged release behavior.
• Load dependency-supply-chain-review for action, image, tool, installer, package, binary, or provenance trust. Do not treat pinned syntax alone as sufficient provenance evidence.
• Use least privilege, explicit trust boundaries, and immutable inputs where the provider and repository policy allow. Avoid passing untrusted event fields to shells or privileged steps without validated structured handling.

Routing

• semantic-versioning owns classifying the release delta and choosing a patch, minor, major, or prerelease version; this skill consumes that policy in checked-in automation.
• Language and test skills own the commands run by jobs and their application behavior; this skill owns the hosted workflow that selects and connects them.
• justfiles owns local command wrappers and recipe design.
• container-engineering owns Dockerfile, OCI image, and Compose behavior that a pipeline invokes.
• rust-desktop-gui owns native desktop bundle requirements, platform prerequisites, and packaged-artifact acceptance criteria. This skill owns target-native runner matrices, artifact handling, signing/notarization automation and secret controls, publication, and rerun safety for those artifacts.
• Consult current official CI or release-provider syntax and API documentation after identifying the configured provider and version.
• git-workflows owns manual tags, branches, pushes, recovery, and other Git operations outside automation.
• systematic-debugging starts investigation of active unexplained CI failures before pipeline changes are proposed.
• release-readiness owns the final ship or hold decision, not this skill.
• For a requested review, load code-review and review-verification-protocol.
• Exclude production deployment infrastructure implementation; route platform, runtime, and deployment-system changes to the relevant infrastructure skill or repository workflow.

Validation and Reporting

• Validate changed configuration with the strongest safe provider-native and repository-owned checks available. Confirm trigger coverage, ref selection, dependency graph, matrix behavior, cache/artifact boundaries, permission scope, concurrency, promotion gates, and release idempotency.
• Report the files changed, workflow behavior changed, checks run and results, remote-only or skipped validation, recovery assumptions, and residual risk.