CI and Release Governance
Goals
Keep build, test, package, and release automation reproducible, least-privileged, and consistent with the repository's published contracts.
Use for
.github/workflows/ design;- NuGet/.NET tool packaging;
- GitHub Action packaging and version tags;
- release/versioning conventions;
- test/coverage/security gates;
- workflow permissions, secrets, artifacts, retention, and triggers.
For workflow YAML syntax and expression quoting, also use authoring-github-workflows.
Rules
- Pin or deliberately version third-party actions; avoid floating behavior in security-sensitive jobs.
- Grant the minimum
GITHUB_TOKEN permissions required by each workflow/job.
- Never place credentials in repository files or logs.
- Keep pull-request validation separate from publishing/release permissions.
- Do not publish packages/releases from untrusted fork code with write credentials.
- Avoid expensive jobs on every event unless their value justifies the cost.
- Keep CLI, JSON schema, NuGet package, and GitHub Action versioning implications explicit.
- Do not remove tests, analyzers, audit checks, or security gates merely to make CI green.
Validation
For workflow changes, validate syntax with actionlint when available. For packaging changes, prefer a local pack/dry-run path before real publication. Publishing a release, NuGet package, container, or marketplace artifact always requires explicit user intent.
Completion
Report changed triggers/permissions, build/test/package impact, validations performed, and any compatibility implications for existing consumers.
1---2name: ci-release-governance-33description: Use this skill when designing or reviewing DotNetRepoInspector CI, release/versioning, package publication, GitHub Action distribution, permissions, artifacts, or automated quality gates. Do not use it for ordinary production-code changes with no pipeline impact.4---56# CI and Release Governance78## Goals910Keep build, test, package, and release automation reproducible, least-privileged, and consistent with the repository's published contracts.1112## Use for1314- `.github/workflows/` design;15- NuGet/.NET tool packaging;16- GitHub Action packaging and version tags;17- release/versioning conventions;18- test/coverage/security gates;19- workflow permissions, secrets, artifacts, retention, and triggers.2021For workflow YAML syntax and expression quoting, also use `authoring-github-workflows`.2223## Rules2425- Pin or deliberately version third-party actions; avoid floating behavior in security-sensitive jobs.26- Grant the minimum `GITHUB_TOKEN` permissions required by each workflow/job.27- Never place credentials in repository files or logs.28- Keep pull-request validation separate from publishing/release permissions.29- Do not publish packages/releases from untrusted fork code with write credentials.30- Avoid expensive jobs on every event unless their value justifies the cost.31- Keep CLI, JSON schema, NuGet package, and GitHub Action versioning implications explicit.32- Do not remove tests, analyzers, audit checks, or security gates merely to make CI green.3334## Validation3536For workflow changes, validate syntax with `actionlint` when available. For packaging changes, prefer a local pack/dry-run path before real publication. Publishing a release, NuGet package, container, or marketplace artifact always requires explicit user intent.3738## Completion3940Report changed triggers/permissions, build/test/package impact, validations performed, and any compatibility implications for existing consumers.
rodri-oliveira-dev